MCP setup for product managers, from first connection to first useful answer

Which route should you use, the connector UI or the command line?

If you do not ship code, use the connector UI. Custom connectors using remote MCP are available in the Claude apps across the Free, Pro, Max, Team and Enterprise plans. You open Customize, then Connectors, choose add a custom connector, paste the remote server URL, optionally set OAuth credentials under advanced settings, and then enable the connector per conversation from the plus button. Free accounts get one connector, which is a real constraint and also a useful one: it forces the choice this page keeps pushing you toward.

Use the command line when you want something the UI cannot express: a server scoped to one project, a server committed to a repository so the whole team inherits it, or a local server running as a process on your own machine. In Claude Code the two shapes are short. A remote server is claude mcp add --transport http <name> <url>. A local one is claude mcp add [options] <name> -- <command> [args...], where the double dash separates Claude Code's own options from the command it runs. Servers that expect an API key take it as an environment variable in the same line.

Neither route is the advanced one. They answer different questions about who else gets this connection.

Where does the server live, and who else gets it?

Scope is the decision people skip, and it is the one that produces surprise later.

Scope	Loads in	Shared with the team	Stored in
Local, the default	Current project only	No	Your own config file
Project	Current project only	Yes, through .mcp.json in the project root	The repository
User	All your projects	No	Your own config file

Precedence runs from the top down: local, then project, then user, then servers provided by a plugin, then claude.ai connectors. Two servers registered under the same name in different scopes will not both apply, and Claude Code warns when it sees the same name in multiple scopes pointing at different endpoints.

Project scope is the one to treat carefully. Committing a server to .mcp.json means everyone who clones that repository is offered it. Claude Code asks for approval before first use in an interactive session, and shows a pending-approval state until then, but in headless runs through claude -p, the Agent SDK or a cloud session, project servers load without prompting. If your team runs anything automated, that difference is the whole security model.

What does a first setup actually look like, step by step?

1. Write the question first, in one sentence. Not "connect our tracker", but "list every bug opened this week that is still unassigned, grouped by area". The sentence decides everything after it.
2. Find the server on the vendor's own documentation page. Whoever owns the data publishes the endpoint. Copy it from there, not from a roundup.
3. Choose the read-only path if one exists. A separate read-only endpoint, a read-only scope or a read-only flag all achieve the same thing: your first week cannot produce a change you then have to undo.
4. Add it at the narrowest scope that works. Local unless you specifically want the team to inherit it.
5. Authenticate. claude mcp login <name>, or /mcp inside a session and follow the browser flow. Servers needing OAuth report a needs-authentication state rather than failing.
6. Verify before trusting. claude mcp list for everything, claude mcp get <name> for one server including its HTTP status and error text.
7. Ask the sentence from step one, and compare the answer to the one you produced by hand last week. That comparison is the only real acceptance test.

Why does the first serious question come back truncated?

Because tool output is capped, deliberately. Claude Code warns at 10,000 tokens of MCP output and caps at 25,000 by default, with a hard ceiling of 500,000 characters, and raising it is one environment variable away. When output exceeds the limit it gets written to a file and replaced by a reference, so nothing is lost, but nothing is in context either.

The instinct is to raise the cap. The better move, almost always, is to narrow the question. "Summarise every ticket in the project" is a request for a data dump the model then has to read back to you. "List open, unassigned bugs tagged urgent from the last seven days, grouped by area" is a request for an answer. The second one also happens to be reviewable: you can tell at a glance whether it is right, which you cannot do with a summary of four hundred tickets.

What should you do before the second server?

Stop, for about a week. One connected server with one proven question is a working system. Two connected servers with no proven question is a config file.

The check to run before adding the second: can you say, without opening anything, what the first server is allowed to do and who approved that? If not, the answer is not another server. It is writing that down. Tool lists also enter the model's context before any work begins, so every extra connection costs something even when it is never used.

For the safety half of this setup, Claude Code permissions and safety covers the approval model around tool calls, and Claude Code setup for product managers covers the environment this all runs inside if you are starting from zero.

What does this save you, and what does it cost?

The saving is narrow and real: the weekly assembly job. Opening four tabs, filtering each one the same way you did last Monday, pasting the results somewhere and writing three sentences about them. A read-only connection plus one well-shaped question collapses that into one prompt, and unlike a dashboard it answers follow-up questions in the same breath.

The cost is a new kind of maintenance. A server you connected in September can change what its tools do in October without telling you, because the tool list is fetched from the server and can change at any time. Credentials expire and connections quietly move to a needs-authentication state. A project-scoped server sits in a repository that new joiners inherit by default. None of that is hard, but it is ongoing, and it belongs to a person rather than to a config file. If you cannot name that person, the honest read is that the setup is a personal tool rather than a team one, which is a perfectly good thing to be as long as nobody plans a process around it.

Where this leads next

Setup is the easy half. The half that decides whether any of it survives contact with a real team is the design underneath: what the assistant is for, what it may reach, and what happens when it is wrong. Builders Camp's Building with Claude Code bootcamp names MCP and tool integrations directly in its syllabus and runs 1 week with 2 live sessions and 9 microlessons, directed by Guilherme Salgueiro, with a practical challenge built around designing the governance layer for an AI operating model that had already broken. AI Agents covers the same judgement at the design level over 2 weeks, and both sit in the AI Agentic Builders Expert Track.

See the Building with Claude Code bootcamp

If the setup does not go cleanly, the failures are unusually legible once you know the five shapes they take. Start from MCP for product managers for the protocol underneath, and building an AI assistant with MCP for scoping the assistant rather than the connection.