Guides / Dev-tool server

Wrapping your own tooling so an agent can use it too

Deploying MCP servers that wrap CI, deploys, and internal dashboards for engineering teams - OAuth 2.1 through company SSO, tested against staging in the Playground, deployed continuously.

best for: engineering teams
state: external, proxied
auth: OAuth 2.1 + SSO

Every engineering org answers the same questions on repeat - did main just break the build, what shipped since yesterday, why is this service's error rate up - usually by someone tabbing over to CI or a dashboard to look it up for whoever asked. Wrapping that lookup as MCP tools (build_status, recent_deploys, error_rate_for_service) turns it into something any engineer's agent can answer directly, without a person acting as the lookup service in between.

Structurally this is close to the internal-connector category: a narrow proxy in front of systems that already exist (CI, the deploy pipeline, an error dashboard), not a new system of record. It deploys the same way any other project on foro does - a repo with a manifest, nothing bespoke about the pipeline - and for a team, the same OAuth-via-company-SSO pattern applies: engineers sign in with the identity they already use everywhere else internally, and each person's access is scoped to that one project.

One thing to design for deliberately in this category: a devtools tool that quietly returns wrong data is worse than no tool at all, because a result that's supposed to be authoritative doesn't get double-checked. The Playground tab is the place to catch that before it ships - call the new tool against real staging data, read the actual response, confirm it isn't lying, then merge. That same Playground call runs through the platform's own PII scrubber - the one guarding the dashboard's chat - which matters when staging data still has a real customer's email sitting in an error message somewhere.

Continuous deployment pays off most visibly here: when an engineer adds a tool and merges to main, foro notices the running container no longer matches the branch and redeploys without a manual step. The gap between “someone had an idea for a tool” and “every agent in the company can use it” becomes however long the build takes, not however long it takes someone to remember to click deploy.

auth OAuth 2.1, SSO, per-engineerdeploy continuous, on push to maintested in Playground, against stagingtools tab calls, p95, errors, per tool

used viaEngineers wire it straight into their IDE's MCP config (Claude Code, Cursor, VS Code); everyone else - support, PM, ops - reaches the same tools by attaching it as a Connector in Claude chat, so “did main just break” doesn't require opening a terminal.

Fits cleanly when the server proxies one or two existing systems rather than trying to become a new one.
Grows into the internal-connector pattern as more of the company's own data gets exposed through it - same platform, same security model, just a wider set of upstream systems behind the tools.