How do you set up MCP servers in YAGNI Code?

What are MCP servers doing in your coding agent?

Model Context Protocol servers are how a coding agent reaches the tools beyond the repo: the issue tracker, the design files, the knowledge base, an internal API. Each one you add lets the agent read, and sometimes act, in another system while it works. Your team likely already has a set of them configured, and the point of this lesson is that they come along.

YAGNI Code supports three server shapes: local stdio servers (a process spawned on your machine), and hosted http and sse servers (a URL the agent connects out to). All three scopes Claude Code uses, project, user, and local, are supported with the same meaning, and the same .mcp.json schema.

How do repo-level servers carry over with zero changes?

If a repo already has a .mcp.json at its root, YAGNI Code reads it as-is. It is the exact Claude Code schema, so a repository configured for Claude Code works here with nothing changed, including ${MY_API_KEY} style environment expansion: secrets stay out of the file and expand from each developer’s own environment.

Because that file is committed to version control, it is shared by the whole team, and a file anyone can add to is not something to auto-run blindly. The first time you open the project, YAGNI Code shows a one-time prompt listing the servers the file defines, and you approve or decline them. Your choice is remembered; yagni mcp reset-project-choices makes the prompt appear again if a new server was added and you want to reconsider.

How do you import your personal servers from Claude Code?

For servers configured in your own Claude Code setup rather than a repo, one command moves them:

yagni mcp add-from-claude

It reads your Claude Code configuration, imports your user-scope servers plus this project’s local ones, and maps each to the matching YAGNI Code scope. Run it in each repo where you had project-local servers. Afterwards, yagni mcp list shows everything configured and health-checks each server, and yagni mcp get <name> and yagni mcp remove <name> inspect or remove a single one.

How do you add a new server by hand?

Hosted and local servers both start with yagni mcp add:

yagni mcp add --transport http sentry https://mcp.sentry.dev/mcp
yagni mcp add my-server -- npx my-mcp-server

The first form registers a hosted http or sse server at a URL, with optional headers for static API keys: -H "Authorization: Bearer ${MY_TOKEN}". The second spawns a local stdio server, passing everything after the double dash as the command, with -e KEY=value for its environment. By default a server lands in local scope, private to you in this directory; -s user makes it follow you across projects, and -s project writes it to the repo’s .mcp.json for the whole team.

How do OAuth logins work inside a session?

Hosted servers usually need you signed in, and OAuth is the normal path for that. Inside a session, type /mcp and the panel lists every configured server with its state: connected, needs authentication, or failed to connect. Select a needs-authentication server and a browser window opens for the login; when it completes, the tokens are stored on your machine and reused from then on, with the refresh flow handled automatically.

Which hosted servers will not connect, and what do you do about them?

A small set of hosted servers, Figma’s remote server being the example most teams hit, are not fully open endpoints: the vendor approves each AI client individually, and only clients on that list get in. This is not a protocol difference. YAGNI Code speaks the same Model Context Protocol and runs the same OAuth flow, but vendor approval is separate from both, and a client not on the list is rejected before any login appears.

If a hosted server refuses to connect and the error mentions a forbidden or unauthorized response, check the vendor’s MCP documentation for a client approval list before debugging your own setup: it is usually them, not you. The workaround while a vendor approval is pending is the same server’s local form, run from the vendor’s desktop app, which has no approval gate because it is your own machine talking to your own files.

Where do you go next?

With your team’s servers connected, the remaining setup step is observability: export the traces to Datadog so every run’s cost and shape is queryable in the stack you already run. For the org-level story, start with Teams.