Measuring the ROI of MCP: A Step-by-Step Playbook

Measuring the return on MCP means proving that connecting AI apps to your business tools saves more than it costs. This job usually falls to an operations lead, an IT manager or a finance-minded owner. MCP changes the measurement problem because the work now happens through tool calls you can count and log, not just chats you have to guess about.

This playbook gives you a repeatable way to measure it. It does not give you a benchmark, because there is no trustworthy industry ROI figure for MCP yet. Your own baseline is the only number that matters.

What you need

You need three things: a client with usage reporting, the servers that run the workflow, and somewhere to keep your numbers.

• A client with analytics. Claude for Teams and Enterprise include a usage dashboard. Anthropic's help article on usage analytics says it shows a "Connectors" view with the number of users plus read and write action counts, an "MCP writes" figure, and a spend report you can export as CSV. On Team plans, Owners and Primary Owners can see it. On Enterprise, Admins can too, but they can't view spend.
• Claude Code telemetry, for developer workflows. Claude Code's monitoring docs list OpenTelemetry metrics such as claude_code.cost.usage, claude_code.token.usage, claude_code.pull_request.count and claude_code.active_time.total, plus a claude_code.tool_result event for each tool call.
• The servers in the workflow. Pick from the MCP server directory and note which tools each one exposes.
• A spreadsheet or BI tool. You will join three sources: your baseline timings, client usage data and cost data.
• Server or gateway logs, if you have them. A gateway gives you one log of every tool call across clients. See MCP gateways explained for what they record.

The workflow

1. Pick one workflow and write down its outcome. Choose a task with a clear finish line, such as "weekly marketing report sent" or "invoices chased." See the other guides in the playbook library for candidates.
2. Record a baseline before MCP. For two to four weeks, log how long the task takes, who does it, how often it needs redoing, and any tool or contractor cost. Use timesheets or a simple log. Don't estimate from memory.
3. Turn on usage reporting. In Claude for Teams or Enterprise, confirm an Owner can open the analytics dashboard. For Claude Code, set CLAUDE_CODE_ENABLE_TELEMETRY=1 and an exporter, as the monitoring docs describe.
4. Decide whether to log MCP tool names. By default, Claude Code replaces the names of user-configured MCP servers with "custom" in cost and API events. Setting OTEL_LOG_TOOL_DETAILS=1 emits real server and tool names, and tool inputs too. Agree on this with whoever owns privacy first, because inputs can contain customer data.
5. Run the pilot on the same workflow. Keep the same people and the same definition of "done." Run it for at least as long as the baseline.
6. Pull usage and adoption data. From the Claude dashboard, export connector reads and writes, active members and the spend report. From Claude Code, the analytics dashboard shows daily active users, sessions, suggestion accept rate and, with the GitHub app installed, "PRs with CC."
7. Pull tool-call health. The claude_code.tool_result event carries success, duration_ms and error_type for every call. Count failed calls and slow calls per server. On other clients, use your server or gateway logs.
8. Add up the full cost. Include seat or usage costs from the spend report, server subscriptions, setup time, review time and any build cost. If you are building your own server, see what MCP server development costs.
9. Compare and decide. Put baseline and pilot side by side for time per task, rework rate, errors and cost. Then keep, change or stop the workflow.

Example prompts

These prompts assume a client with the relevant servers connected. They only ask for data those servers document.

• "Using the analytics CSV I uploaded, summarize connector reads and writes per week for the last eight weeks and flag any week where writes rose but active members fell."
• "Read the tool-result events in this export. Group them by MCP tool name and show the success rate and median duration for each."
• "Compare these two tables: baseline task timings and pilot task timings. Show the change in minutes per task and the change in rework count, without rounding."
• "List every tool call in this log that returned an error, with the server, the tool and the error type."

Guardrails

Measurement can create its own risk, so set rules before you collect data.

• Collect the least data you need. Claude Code's monitoring docs say user prompt content is redacted unless you enable OTEL_LOG_USER_PROMPTS. Leave it off unless you have a reason and a retention policy.
• Keep humans in the loop while you measure. The MCP tools specification says there "SHOULD always be a human in the loop with the ability to deny tool invocations." Don't remove approvals just to make the numbers look faster.
• Log for audit, not only for ROI. The same spec section says clients should "log tool usage for audit purposes." The OWASP MCP Top 10 lists "Lack of Audit and Telemetry" as MCP08. Our MCP audit logging guide covers what to keep.
• Treat vendor metrics as estimates. Anthropic's own analytics docs call its contribution metrics "deliberately conservative." Other dashboards may lean the other way. Either way, check them against your baseline.
• Keep judgment calls human. Deciding whether a workflow is "worth it" includes risk and quality, not only hours. That decision belongs to a person.

For the wider controls, see the MCP security center.

What to measure

Track these per workflow, before and after. Don't copy targets from blogs: set your own after the baseline.

Anthropic's usage analytics also include an "Estimated time saved" metric, per its help article. Use it as a pointer, then confirm with your own timings. For developer teams, the Claude Code analytics docs suggest pairing its numbers with DORA metrics or sprint velocity rather than reading them alone.

A simple formula works: (baseline hours minus pilot hours) times a loaded hourly rate, minus the full added cost. If the result is negative or unclear after a fair pilot, the workflow isn't ready yet.

Next step

If you want help choosing the first workflow to measure and setting up the baseline, start with an MCP readiness audit. For the rollout plan around it, see MCP governance for IT leaders.

Frequently asked questions