MCP server for product management

An MCP server for product management lets your coding agents read the ranked work, the specs and what you decided, then report back to the same place. It is the line between your plan and Claude Code, Cursor, Codex and Grok, so nobody pastes the plan into a prompt again.

MCP (Model Context Protocol) is an open protocol from Anthropic that lets an AI tool call outside tools and read outside data.

When to use it: when agents need to know what to work on without asking you, or when more than one agent builds. When not: skip it if one agent works from a single short plan you already keep in a rules file.

What is an MCP server, in plain words?

An MCP server is a small program that offers an AI tool a set of things it can do or read. Your agent is the client, and the server is the other end of the line. The protocol's own site puts it as "a USB-C port for AI applications": a service builds one server, and any app that speaks the protocol can use it.

• Host. The app you work in, such as Claude Code or Cursor.
• Client. The piece inside the host that keeps one connection to one server.
• Server. The program on the other end that offers tools and data.

Without a server, product context reaches an agent in 3 ways, and all of them leak.

For product work, typical jobs are to ask what to work on next, claim it, file what you found along the way and record how you checked it. For the full definitions, see MCP server and Model Context Protocol.

What does an MCP server do for product work?

A product-management MCP server uses MCP so your agents read your plan directly. Nobody copies a ticket into a prompt, and the agent reads the live list, not a pasted copy.

Two things change. The agent can find out what to work on without asking you. And what it learns goes back to the same place instead of ending with the session.

Without a server, product context reaches an agent in 3 ways, and all of them leak. You paste a ticket, and the paste is out of date by Thursday. You keep a plan in a rules file, and the file grows until nobody reads it. Or you explain it in chat, and the explanation is gone when the session ends. A server swaps all three for one live read. For the wider picture of what agents need to know before they build, see how to give AI coding agents product context.

What should a product-management MCP server let agents do?

Whatever server you pick, check that your agents can do these six things:

1. Read the ranked list and the specs. What is next, why, and what done means.
2. Claim work. So the list shows who holds what and two agents do not start the same job.
3. File findings. A bug or idea the agent found goes on the list, not into a chat.
4. Ask a person. A real question reaches you in a few lines, and the answer is saved.
5. Ship with receipts. The agent checks each Done When line and records how.
6. Keep the person in charge. Some actions, like emailing customers, should stay a person's call.

Also check how it signs in. A browser sign-in with OAuth beats a token in a config file.

What is the difference between a remote and a local MCP server?

Where the server runs decides most of what you live with: how you install it, how you sign in and who keeps it up to date.

A remote server gives each of them the same live copy, which a server on one machine can't.

A local server is a program your agent starts on your own machine. It talks over standard input and output, which the spec calls stdio, and it serves one client. It is the right choice when the job is on your machine: your files, your tests, your browser.

A remote server lives at a URL. Your agent connects over HTTP, which the spec calls Streamable HTTP, signs in through the browser and calls tools the same way it would call a local one. One deployment serves every person and every agent, and an update lands for everyone at once.

Product work is the remote case. Your priorities, specs and decisions don't live on one laptop. Everyone on the team and every agent shares them. A remote server gives each of them the same live copy, which a server on one machine can't.

A note if you read older guides: some still describe an SSE transport for remote servers. Claude Code's docs now say "The SSE (Server-Sent Events) transport is deprecated" and point to HTTP instead. And if a guide tells you to install something to reach a service that already has a URL, try the URL first. The longer version is in what is a remote MCP server?

Should a server's tools read or act?

Split them, and say which is which. A tool that only reads can't hurt anything: the worst it does is use up some of the agent's attention. A tool that acts changes something other people see, like the list, a spec or a customer's inbox. Those deserve different levels of trust.

A good product server makes the split obvious in 3 ways:

1. Read tools sit apart from act tools. So you can allow every read without a second thought and decide each act on its own.
2. Act tools are grouped by how much they can change. Adding a note to a job is not the same as merging 2 priorities or emailing a customer. If one tool does all of those, you can only allow all of it or none of it.
3. Some actions belong to a person, whoever asks. Signing a decision, answering a question in your name and telling customers something shipped should need a person, even when an agent is the one asking.

Most MCP clients ask you before a tool runs until you say otherwise. Cursor's docs say it asks for approval before using MCP tools by default, and Claude Code lets you allow tools one at a time. That only helps if the server's tools are split well. A single "do anything" tool turns every approval into a guess.

What are Annsa's eight tools?

Three read and change nothing:

• annsa.priorities: see what to work on next, ranked, with the evidence behind it
• annsa.spec: read the plan for one priority: what to build, why, and Done When
• annsa.ask: ask about your customers, your work or Annsa itself

Five write:

• annsa.work: do the work on a priority, and settle routine asks with undo
• annsa.file: add what a customer said, what an agent found, or a new idea
• annsa.decide: record a decision: your answer, a spec edit, or a rule
• annsa.board: arrange the board. A merge retires numbers for good
• annsa.share: tell the customers who asked that it shipped. Emails can't be unsent

Which should I let run? Let annsa.work and annsa.file run without asking. Approve annsa.decide, annsa.board and annsa.share each time, because they change what you decided or what your customers hear. Sharing is a person's call, so an agent credential is refused it.

The full list of actions inside each tool, and which ones only a person may run, is in Tools and actions.

What does product work need from a server, and how do I check?

Use this table on any server you try, Annsa's included. The middle column is the test. Run it on a real priority, not a demo.

If a server fails the first 2 rows, it is a ticket viewer, not a source of direction. If it fails the last 2, think hard before you allow its writes.

How do I connect Claude Code, Cursor, Codex and Grok?

Annsa is a remote server at https://app.annsa.ai/mcp. There is nothing to install. The first run opens a browser for sign-in.

Claude Code

claude mcp add --transport http annsa https://app.annsa.ai/mcp

Codex (starts the browser sign-in itself; if it doesn't, run the second command)

codex mcp add annsa --url https://app.annsa.ai/mcp
codex mcp login annsa

Grok

grok mcp add --transport http annsa https://app.annsa.ai/mcp

Cursor has a one-click install in the Annsa docs. Or go to Settings, then MCP, then Add server, and paste https://app.annsa.ai/mcp.

Each agent keeps its own connection and reads the same priorities, specs and decisions. Full steps: Connect your agent.

What is the command for each agent?

Claude Code:

claude mcp add --transport http annsa https://app.annsa.ai/mcp

Cursor: use the Add to Cursor button on the Cursor page, or open Settings, then MCP, then Add server, and paste the same URL.

Codex, then Grok:

codex mcp add annsa --url https://app.annsa.ai/mcp
grok mcp add --transport http annsa https://app.annsa.ai/mcp

Auth is OAuth in the browser.

What happens the first time?

Your agent calls the server, the server says it needs a sign-in, and your browser opens on a consent screen. Approve once. From then on the agent acts as you, with your rights, until you remove the server from its settings. There is no key to copy.

Most agents load their servers when a session starts, so a server added mid-session needs a new session. If a call later says unauthorized, reconnect from the agent's MCP settings instead of sending the same call again. Each agent has its own page with its own fixes: Claude Code, Cursor, Codex and Grok.

Should I add it for one project or for all of them?

Claude Code can add a server for one project, for every project you open, or for the whole team through a shared file in the repo. It asks before it uses a shared project server for the first time. Cursor has the same split between a project file and a global one. For a product server, adding it once for yourself across projects is usually enough, since each person signs in as themselves anyway.

Is an MCP server safe, and what should I let it do?

An MCP server is as safe as what it can reach and who it acts as. Five plain questions cover most of it.

Who does the agent act as? With a browser sign-in, the agent acts as you, with your rights. That is handy, and it means the agent can do anything you can. Some servers also let you create a separate agent credential with fewer rights. Use one when you want certain calls to stay with a person whatever happens.

How does it sign in? OAuth in the browser keeps secrets out of files on your laptop and lets you cut access off in one place. A long-lived key pasted into a config is a key anyone with that file has. The MCP docs themselves recommend OAuth for remote servers.

What can each tool change? Read the tool list before you allow anything. Allow the reads. Allow the everyday writes once you trust them. Keep the rest on approve-each-time.

Could what comes back steer the agent? A server that returns text other people wrote, like customer messages or web pages, can carry instructions the agent might follow. This is called prompt injection. Claude Code's docs say it plainly: "Verify you trust each server before connecting it." Treat what comes back as data, and keep customer-facing actions behind a person.

Can you see what happened? Every action an agent takes should leave a trail with its name on it, so you can tell its changes from yours.

If you build servers yourself, the MCP project keeps a longer list of attacks and fixes, and how to add OAuth to an MCP server walks through the sign-in step by step.

Treat what comes back as data, and keep customer-facing actions behind a person.

What mistakes do people make with MCP servers?

• Connecting every server they find. Each server's tools sit in front of the agent all session. More tools mean more chances to pick the wrong one. Connect the few you use every week.
• Allowing every tool on day one. Start with reads. Add writes one at a time, as you see how the agent uses them.
• Pasting secrets into configs that end up in the repo. If a server needs a key in a file, keep that file out of version control, or pick a server that signs in through the browser.
• Treating a local copy as the team's plan. One laptop's server is one person's view. A plan several agents share needs one address.
• Keeping a second plan somewhere else. If agents read one list and you work from another, they drift by Wednesday.
• Writing to the wrong workspace. If you keep a test workspace and a live one, have the agent say which it is in before its first write.
• Expecting the ranked list to be the call. The list is where the agent starts. A person makes the call on anything that matters.

What does a week with a product server look like?

Say a three-person team with 40 customers runs Claude Code and Codex. This is a made-up week, to show the shape.

Monday. The founder adds the server to both agents and signs in twice in the browser. Claude Code reads the list and claims #12, a sync bug a person marked P1. Codex reads the list, sees #12 is held and claims #14, a bulk export 6 accounts asked for.

Tuesday. Codex finds a flaky test on the way. It files it as a finding with a proposed P2, and the finding lands on the list instead of in a chat log.

Wednesday. Claude Code hits a real choice: keep the old export format for 2 weeks or switch now. It raises the question in 3 lines. The founder answers in a minute, and the answer is saved on the spec.

Thursday. Codex starts a related job and reads that answer before it asks. Claude Code checks each Done When line, records a receipt for each and ships. One line, about an email on production, it couldn't check, so it says so.

Friday. A note to each person who asked for the export is drafted. The founder edits one line and sends it.

Nobody pasted a ticket all week, and nobody answered the same question twice.

A checklist before you connect a product server

• It is remote, at one URL, with OAuth in the browser
• Read tools are separate from act tools
• Customer-facing actions need a person by default
• An agent can claim work, and a second agent can't take it silently
• Findings land on the same list as customer requests
• Questions to you are short, and answers are saved
• Done is backed by a receipt per line
• Every action shows who did it

How does Annsa keep me in charge?

Annsa is project management and customer feedback software for founders and small teams working with AI agents. MCP connects the agents you already use to the shared plan, so they can read priorities, record progress and bring you decisions that need your call.

• One agent holds each priority at a time, so agents do not collide.
• There are two paths to shipped. Your agent can mark a priority shipped; any Done When line it couldn't check is labeled on the spec, and that's your call. A merged pull request that names the priority ships it automatically only when it reaches your live branch and every Done When line has a receipt; otherwise it's held with a note.
• Signed in through the browser, an agent acts as you, so set your editor to ask before the three tools that change what you decided or what customers hear. With an agent credential, person-only actions, including sharing with customers, are refused.
• A person makes the call. Annsa drafts the customer notes; you review and send them.

• One URL, 8 tools. A remote server at app.annsa.ai/mcp, with OAuth in the browser and nothing to install. 3 tools read and 5 act.
• Two kinds of sign-in. Signed in through the browser, an agent is you. An owner can also create an agent credential in Settings → Integrations → Agents → New agent, with read or write scope. It expires after 365 days, and a person-only action is refused to it.
• A trail. Agent actions land in the activity log and on the spec's history with the agent's name on them.
• Limits you can see. MCP calls are capped at 1,000 an hour.

See Tools and actions, Hand work to any agent and Direct your agents.

Sources

• Model Context Protocol, What is the Model Context Protocol (MCP)?: the definition and the USB-C comparison.
• Model Context Protocol, Architecture overview: host, client and server; stdio and Streamable HTTP; OAuth recommended.
• Anthropic, Introducing the Model Context Protocol, 25 November 2024.
• Anthropic, Connect Claude Code to tools via MCP: SSE deprecated; trust each server.
• Cursor, Model Context Protocol (MCP): approval before MCP tools run.