Measure MCP Server Token Costs

Measure and reduce the per-turn token cost of your MCP server tools.

Introduction

30 Second Summary

A short question can carry a surprisingly long hidden attachment. When that attachment repeats with every message, small chats become harder to understand and more expensive to run.

In this project, you will measure the input tokens that your connected Model Context Protocol (MCP) servers add to every turn. Your final result is a tool list with fewer than ten entries plus a chart of the before and after cost.

What You'll Build

Run your finished measurement against your MCP setup to produce a before-and-after chart showing the exact input cost you removed from every turn.

By the end of this project, you'll have:

  • A complete tool inventory containing every exposed name. Each entry preserves its description plus schema.
  • A reusable per-turn cost script that converts your own token count using your model's input rate.
  • A before-and-after chart backed by response measurements from the same short message. The chart shows exactly what the trimmed configuration saves each turn.
  • Secret Mission: Add an automated tool-budget check that warns you when a server pushes the exposed list above your limit.

Are there any prerequisites?

You need an MCP-compatible AI agent plus two MCP servers you can connect. Your token measurement can come from a token counter or the input token count returned with each model response.

Before We Start

Tool definitions from every connected Model Context Protocol (MCP) server become input for the model. To measure that overhead, you need a setup that exposes the server configuration plus the input tokens reported for a response.

In this step, you'll confirm Python 3.11 or later. You'll also open a local code editor.

You'll prepare an MCP-capable agent whose server configuration and response usage are accessible. You'll record the input price for your selected model.

In this step, get ready to:
  • Confirm your local terminal runs Python 3.11 or later.
  • Open a local code editor.
  • Prepare an MCP-capable agent with pricing data plus response usage access.
Check Python and local tools

Python powers the measurement script you build later. Checking the active interpreter now prevents version problems from muddying your token results.

macOS

  • Press Cmd+Space to open Spotlight.
  • Type Terminal into Spotlight.
  • Press Enter to open Terminal.
  • Check the active Python version by running this command:
python3 --version

What does this command do?

The command asks your active Python 3 interpreter to print its version. It exits immediately after showing the result.

Windows

  • Press the Windows key to open Start search.
  • Type PowerShell into Start search.
  • Press Enter to open PowerShell.
  • Check the active Python version by running this command:
py --version

What does this command do?

The command asks the Windows Python launcher to print the version it selects. It exits immediately after showing the result.

  • Choose the tab below that matches your terminal output.

✔️ I see Python 3.11 or higher

That's one foundation ready. Your Python interpreter meets the version required for the measurement script.

ⓧ I see an older Python version

Your terminal currently points to an older interpreter. Install a current Python 3 release before continuing.

  • Visit the official Python downloads page.
  • Download the current installer for your operating system.
  • Run the downloaded installer.
  • Follow the installer's prompts to complete the installation.
  • Close your current terminal window.
  • Open a fresh terminal using the platform steps above.
  • Run the matching version-check command from the platform tab again.

You should now see Python 3.11 or a higher version.

Still seeing an older version on macOS?

macOS can keep a Python.org installation beside an older system installation. Follow the official macOS configuration guidance to make your terminal use the Python.org installation.

ⓧ Command not found

Python is unavailable from your current terminal. The official installer adds the interpreter you need.

  • Visit the official Python downloads page.
  • Download the current installer for your operating system.
  • Run the downloaded installer.
  • Follow the installer's prompts to complete the installation.
  • Close your current terminal window.
  • Open a fresh terminal using the platform steps above.
  • Run the matching version-check command from the platform tab again.

You should now see Python 3.11 or a higher version.

Python check still not working?

A terminal that stayed open during installation may still use its old program path. Close every terminal window before opening a fresh one.

If the fresh terminal still cannot find Python, compare your installation with the official platform instructions linked above.

Help me diagnose my Python installation.

The standard Python distribution includes IDLE. It gives you a local editor for the script you create later.

  • Press Cmd+Space on macOS or the Windows key on Windows to open system search.
  • Type IDLE into the search field.
  • Press Enter to open the editor.

You now have a local terminal for running scripts plus an editor for changing them.

Cannot find IDLE?

Use another local code editor already installed on your computer. You can also return to the official Python installer to complete the standard installation.

Help me get a local code editor ready.

Prepare your MCP-capable agent

An MCP host is the agent application you interact with. Its internal client connections communicate with individual MCP servers.

Your chosen agent must expose its MCP server configuration. It must also let you inspect input-token usage through response details or provider records.

  • Choose an agent application whose official documentation confirms MCP server support.
  • Confirm its documentation provides access to per-response input-token usage or raw response details.
  • Record the agent you selected: your MCP-capable agent.
  • Install the agent using its official installation guide.
  • Start the agent using the launch method in its official guide.

Authentication can feel sensitive. Keep every access credential inside the agent's documented sign-in or credential flow.

  • Complete the agent's documented authentication process.
  • Open a blank conversation in the agent.
  • Use the agent's official MCP documentation to locate its server configuration.
  • Record the configuration location: your MCP configuration file or settings page.
  • Confirm the configuration has a place for adding MCP server entries.

You should now be able to point to the exact file or settings page where the next step adds two servers. That access makes every later before-and-after comparison reproducible.

Why does configuration access matter?

The configuration determines which MCP servers can expose tools to your agent. Later, you change that configuration to remove a server plus trim the available tools.

Cannot find the MCP configuration?

Search your agent's official documentation for its MCP server setup guide. Check that your installed edition supports configurable MCP connections.

Help me locate my agent's MCP configuration.

Record pricing and usage access

The input-token rate converts your measured token count into a cost per turn. Use the standard input rate for the exact model selected in your agent.

Pricing tables can be fiddly because one model may have separate standard input, cached input, or long-context rows. Match the model name plus the pricing tier used by your tests.

  • Record the model selected in your agent: your selected model.
  • Open that model provider's official pricing page.
  • Find the standard input price for your selected model.
  • Convert the listed input price to a rate per one million tokens if needed.
  • Record the rate here: your model input price per one million tokens.
  • Use your agent's official documentation to locate response token-usage details.
  • Record where you found them: where your client shows response token usage.

Before you send the test message, do you expect its input-token count to be zero or positive?

  • Enter Reply with one word: ready. in the blank conversation.
  • Submit the message using your agent's send control.
  • Open the response usage location you recorded.

You'll see a positive input-token count associated with the response. This proves you can observe the measurement used throughout the project.

No input-token count visible?

Check the agent's raw response details or the provider's request records. Some clients keep usage outside the main conversation view.

If neither location exposes input tokens, choose a supported client workflow that provides this evidence before continuing.

Help me find response token usage.

Your measuring setup is ready. Next, you'll connect two MCP servers and reveal the full tool list they add to every turn.

Connect Servers and List Tools

Your cost measurement needs a trustworthy baseline. Each connected Model Context Protocol (MCP) server contributes tools that the agent includes in its working context.

First, you will connect two servers under consistent names. You will then print every exposed tool with its source server.

In this step, get ready to:
  • Connect your first MCP server under the name Server A.
  • Connect your second MCP server under the name Server B.
  • Print the complete combined tool list with a source server for every tool.
Connect Server A

A server connection gives your agent access to the tools exposed by that server. The label Server A gives the first connection a stable name for your baseline.

  • Switch back to the agent's MCP configuration file from earlier.
  • Add your first available MCP server connection under the name Server A using its existing connection details.
  • Save the MCP configuration file.
  • Reload the MCP configuration in your agent client.
  • Confirm that Server A shows a connected state with at least one available tool.

That first connection is live. Your client now has a tool source labeled Server A.

Server A Not Connecting?

  • Check the connection details against the settings supplied by your first server.
  • Confirm that the configuration entry uses the name Server A.
  • Reload the MCP configuration after saving the file.

Help me diagnose why my first MCP server does not connect.

Connect Server B

The second connection creates the combined tool surface you will measure. Its Server B label preserves the source of every tool it contributes.

  • Switch back to the same MCP configuration file.
  • Add your second available MCP server connection under the name Server B using its existing connection details.
  • Save the MCP configuration file.
  • Reload the updated MCP configuration in your agent client.
  • Confirm that Server B shows a connected state with at least one available tool.
  • Confirm that Server A remains connected.

Both tool sources are now active. Your agent can expose tools from the two servers in the same session.

Only One Server Connected?

  • Confirm that the two configuration entries have different names.
  • Check the connection details for the server that remains disconnected.
  • Reload the configuration after saving both entries.

Help me find why only one of my two MCP servers connects.

Print the Combined Tool List

Your agent merges tools from both connections into one available tool surface. Source labels let you trace every entry back to the server that introduced it.

Before you request the list, which server names do you expect to see beside the tools?

  • Return to the terminal session used by your agent.
  • Ask your agent to print every currently available MCP tool with its exact tool name plus source server.

You should see at least one tool attributed to Server A. You should also see at least one tool attributed to Server B.

  • Compare the terminal output with the tool inventory for each server in your agent client.
  • Confirm that every available tool appears in the terminal with the correct source server.

A matching inventory proves that the terminal output contains the complete combined tool list. You now have the baseline that every later cost comparison depends on.

Missing Tools From the Output?

  • Confirm that both servers still show a connected state in the agent client.
  • Reload the MCP configuration before requesting the list again.
  • Request exact tool names plus source servers without asking the agent to summarize the list.

Help me work out why my combined MCP tool list is incomplete.

Your two-server baseline is visible. Next, you will capture the definitions behind these tool names so you can measure their full size.

Export Tool Definitions

You already proved that Server A and Server B expose a combined tool list. Tool names reveal only part of the input your agent receives.

This step captures every Model Context Protocol (MCP) tool definition in one baseline file. You will verify its contents before recording its size.

In this step, get ready to:
  • Export the complete definitions for every tool exposed by both servers.
  • Audit every definition for its name, description, and input schema.
  • Record the baseline size of the exported file.
Export the complete definitions

A tool definition is a structured JSON object that tells the model when a tool fits. Its input schema describes the arguments the tool accepts.

What belongs in a tool definition?

  • The name identifies the tool the model can call.
  • The description explains the tool's purpose to the model.
  • The input schema defines the accepted arguments.
  • Switch back to the MCP-capable agent client from earlier.
  • Return to the MCP tool inspection workflow that produced your combined tool list.
  • Use the client's schema or export option to reveal the complete structured definition for every connected tool.
  • Confirm that the output includes tools from Server A.
  • Confirm that the output includes tools from Server B.
  • Copy the complete structured output.

Keep the full schemas

Copy every nested property inside each input schema. Omitting nested fields would make the baseline smaller than the tool payload your model receives.

  • Use your code editor's new-file control to create a blank file.
  • Save the blank file to your Desktop as mcp-tools-before.json.

You should now see mcp-tools-before.json in your editor. Its tab should show the exact filename.

  • Paste the copied tool definitions into mcp-tools-before.json.
  • Save mcp-tools-before.json.

Good progress. Your baseline file now holds the payload that tool names alone could not show.

Missing the full definitions?

Make sure you are viewing tool details instead of the shorter enabled-tools list. Look for a client option that exposes schemas or structured tool data.

If the client displays one server at a time, export both sets into the same file. Preserve one valid JSON container around all definitions.

help me locate the full MCP tool definitions in my agent client

Audit every exported tool

A complete baseline needs the same tools as your printed list. Each matching definition also needs all three required parts.

  • Switch back to the combined tool list printed in your terminal.
  • Compare each printed tool name with the entries in mcp-tools-before.json.
  • Inspect every matched definition for a non-empty name.
  • Inspect every matched definition for a non-empty description.
  • Inspect every matched definition for a complete input schema.
  • Confirm that the number of exported definitions matches the number of printed tools.
  • Save mcp-tools-before.json after correcting any missing definition.

Your exported count should match the terminal list exactly. Every exported entry should contain a name, a description, and an input schema.

Do the counts differ?

Check whether your client grouped tools by server. A collapsed server section can leave an entire group out of the copied output.

Check the beginning and end of the file for a partial copy. Repeat the export if the outer JSON container or final definition is incomplete.

help me compare my printed MCP tool list with my exported definitions

Record the baseline file size

The file size gives you a concrete baseline before token counting. Recording the exact unit keeps your later comparison consistent.

Before you check the file size, which part do you expect to occupy the most space: names, descriptions, or input schemas?

macOS

  • Press Command-Space bar to open Spotlight.
  • Type Finder in the search field.
  • Press Return to open Finder.
  • Select the Desktop folder in the Finder sidebar.
  • Select mcp-tools-before.json.
  • Press Command-I to open Get Info.
  • Read the exact byte count beside Size.

Windows

  • Press the Windows logo key + E to open File Explorer.
  • Select the Desktop folder in the left pane.
  • Right-click mcp-tools-before.json.
  • Select Properties.
  • Select the General tab.
  • Read the exact byte count beside Size.

You should see a non-zero size for mcp-tools-before.json. The completed audit confirms that this size represents every exposed definition.

  • Record the exact byte count here: your baseline byte count.

That baseline is now locked in. You have a complete tool-definition file with a measured size to compare after trimming.

Your full MCP tool payload is captured. Next up, you will count its tokens and calculate what those definitions cost per turn.

Calculate Token Cost

Your MCP export now captures every definition exposed by Server A plus Server B. The next goal is to translate that file into a per-turn price.

A character count cannot show the input units billed by your model. A tokenizer converts the complete export into tokens.

In this step, get ready to:
  • Install Transformers for access to the selected model's tokenizer.
  • Create a reusable script that counts tokens plus calculates their input cost.
  • Generate the baseline cost report for mcp-tools-before.json.
Prepare the tokenizer dependency

Transformers provides AutoTokenizer for loading the tokenizer associated with a model. Your script can use that tokenizer to count the complete export.

  • Switch back to the local terminal from earlier.
  • Add Transformers to your Python environment by running:
pip install transformers

What does this command add?

  • The transformers package provides model-specific tokenizers through one Python library.
  • AutoTokenizer selects the tokenizer implementation associated with the identifier you provide.
  • The tokenizer files are cached locally after their first download.
  • Wait for the installation command to finish.

Your terminal returns to its prompt without reporting a package installation failure.

Transformers did not install?

  • Run the installation command in the same Python environment that you use for this project.
  • Check your internet connection if the package download stops.
  • Confirm that your terminal still uses Python 3.11 or later.

Help me fix my Transformers installation.

Build the reusable cost script

The calculator needs three inputs each time it runs. These are the exported file, the tokenizer identifier, plus the input price per one million tokens.

  • Switch back to the code editor from earlier.
  • Use your editor's new-file control to create measure_mcp_tool_cost.py beside mcp-tools-before.json.
  • Paste this code into measure_mcp_tool_cost.py:
import sys

from transformers import AutoTokenizer

# Accept the export, tokenizer, and input rate from the command line.
tool_file, tokenizer_name, input_rate_per_million = sys.argv[1:]

# Read the complete serialized tool definitions.
with open(tool_file, encoding="utf-8") as file:
    tool_definitions = file.read()

# Count every token with the selected model's tokenizer.
tokenizer = AutoTokenizer.from_pretrained(tokenizer_name)
token_count = len(tokenizer.tokenize(tool_definitions))

# Convert the model's per-million rate into one turn's input cost.
cost_per_turn = token_count / 1_000_000 * float(input_rate_per_million)

# Print a baseline report that can be compared after trimming.
print(f"File: {tool_file}")
print(f"Tokenizer: {tokenizer_name}")
print(f"Token count: {token_count:,}")
print(f"Estimated input cost per turn: {cost_per_turn:.8f}")

What does this code do?

  • The three command-line values let you reuse the script with another export, tokenizer, or rate.
  • tool_definitions holds the complete serialized file. This keeps every tool name, description, plus input schema in the measurement.
  • tokenizer.tokenize() splits the export according to the selected model's tokenizer.
  • cost_per_turn scales the token count to one million tokens. It then applies the recorded input rate.
  • Save measure_mcp_tool_cost.py.
  • Confirm your editor's file sidebar shows measure_mcp_tool_cost.py beside mcp-tools-before.json.

Script file missing from the sidebar?

  • Check that the filename ends with .py.
  • Move the file beside mcp-tools-before.json if your editor saved it elsewhere.
  • Save the file before checking the sidebar again.

Help me locate my Python script.

✔️ Awesome, I've got everything!

Your reusable cost calculator is saved beside the baseline export.

ⓧ I'd like to double check the full code

import sys

from transformers import AutoTokenizer

# Accept the export, tokenizer, and input rate from the command line.
tool_file, tokenizer_name, input_rate_per_million = sys.argv[1:]

# Read the complete serialized tool definitions.
with open(tool_file, encoding="utf-8") as file:
    tool_definitions = file.read()

# Count every token with the selected model's tokenizer.
tokenizer = AutoTokenizer.from_pretrained(tokenizer_name)
token_count = len(tokenizer.tokenize(tool_definitions))

# Convert the model's per-million rate into one turn's input cost.
cost_per_turn = token_count / 1_000_000 * float(input_rate_per_million)

# Print a baseline report that can be compared after trimming.
print(f"File: {tool_file}")
print(f"Tokenizer: {tokenizer_name}")
print(f"Token count: {token_count:,}")
print(f"Estimated input cost per turn: {cost_per_turn:.8f}")
Measure the baseline cost

A trustworthy baseline uses the tokenizer that matches your selected model. It also uses the model's recorded input price on a per-million-token basis.

Tokenizer identifiers can be fiddly because the model name plus tokenizer repository may differ. Use the identifier documented for your selected model.

  • Use the selected model's tokenizer documentation to identify its model repository or local tokenizer path.
  • Record that identifier as selected model tokenizer identifier.
  • Express your recorded input-token rate as the price for one million tokens.
  • Record the numeric price without a currency symbol as input price per million tokens.

The first baseline run may spend a minute or two downloading tokenizer files. Later runs reuse the local cache.

Before you run the measurement, do you expect the baseline to be closer to hundreds or thousands of tokens?

macOS

  • Run the baseline measurement with Python by using this command:
python3 measure_mcp_tool_cost.py mcp-tools-before.json "[[TOKENIZER_NAME="selected model tokenizer identifier"]]" "[[INPUT_RATE_PER_MILLION="input price per million tokens"]]"

This passes the baseline export, selected tokenizer, plus normalized input rate to the script.

Windows

  • Run the baseline measurement with Python by using this command:
python measure_mcp_tool_cost.py mcp-tools-before.json "[[TOKENIZER_NAME="selected model tokenizer identifier"]]" "[[INPUT_RATE_PER_MILLION="input price per million tokens"]]"

This passes the baseline export, selected tokenizer, plus normalized input rate to the script.

You'll see the export filename in the report. The tokenizer identifier appears below it.

The report then shows the baseline token count. Its final line shows the estimated input cost per turn.

You have turned the hidden tool-list overhead into a number you can compare. That baseline gives every later trim a measurable target.

  • Record the reported token count as baseline token count.
  • Record the final cost as baseline cost per turn.

Baseline report did not appear?

  • Check that your terminal is in the folder containing both project files.
  • Remove any currency symbol or thousands separator from the input-rate value.
  • Use the tokenizer repository or local path documented for your selected model.

Help me debug my token cost script.

Your baseline now captures the token overhead from both connected servers. Next, you'll disconnect one server plus compare input usage from two matching messages.

Compare Live Input Usage

Your exported definitions gave you a calculated baseline for the tool overhead from both servers. A live response now tests whether that overhead appears in the input sent through the Model Context Protocol (MCP).

You will measure the same short message under two connection states. The only planned change is Server B's connection.

In this step, get ready to:
  • Capture the live input-token count with Server A plus Server B connected.
  • Disconnect Server B from the agent configuration.
  • Repeat the test with Server A to calculate the live input-token difference.
Measure the two-server response

Every exposed MCP tool definition contributes to the input sent with a request. The response usage details turn that hidden context into a live count.

  • Switch back to the MCP-capable agent client from earlier.
  • Start a fresh conversation for the two-server test.

The fresh conversation has no earlier messages adding tokens to this test.

  • Confirm Server A is connected in the agent's connection status.
  • Confirm Server B is connected in the agent's connection status.

You should see both servers connected before you capture the baseline response.

  • Enter Reply with exactly OK. in the chat input.
  • Send the message.

You should see OK as the brief response.

  • View the usage details attached to this response.
  • Locate the reported input-token count.
  • Record the count here: your two-server input token count.

You now have a live baseline from a real response with both server tool lists attached.

Can't Find Input Usage?

  • Expand the metadata available for the response.
  • Look for the value that identifies the tokens received by the model.

If your client still hides that value, help me find the input-token usage for a response in my MCP-capable agent client.

Disconnect Server B

Editing the agent configuration can feel risky. You are removing only Server B's connection entry.

The existing mcp-tools-before.json file remains your historical snapshot of both servers. The baseline cost report also stays unchanged.

  • Switch back to the agent's MCP configuration file from earlier.
  • Locate the complete connection entry named Server B.

You should see Server B in a separate connection entry from Server A.

  • Remove the complete Server B connection entry.
  • Save the MCP configuration file.

Your saved configuration should now contain the existing Server A connection without Server B.

  • Restart the agent client to reload the saved MCP configuration.
  • Review the agent's connection status for the configured servers.

You should see Server A connected. Server B should no longer appear as connected.

That is the key isolation done. Your next response can expose Server B's live input cost.

Configuration Won't Reload?

  • Use your editor's undo action to restore the removed entry.
  • Check the separators around the Server B entry before removing it again.
  • Confirm the remaining Server A entry still follows the configuration file's existing structure.

For client-specific help, help me remove one MCP server entry while preserving the remaining server configuration.

Repeat the test and compare counts

A fresh conversation prevents earlier chat history from changing the second input count. Reusing the exact message keeps Server B's connection as the planned difference.

  • Start a fresh conversation for the one-server test.
  • Confirm only Server A is connected.

Your second test now starts with one connected server plus no previous conversation history.

  • Enter Reply with exactly OK. in the chat input.

Before you send it, do you expect the input-token count to rise or fall after disconnecting Server B?

  • Send the message.

You should see OK again. The response text now matches the first test.

  • View the usage details attached to the second response.
  • Locate the reported input-token count.

The second response usage now gives you the one-server measurement.

  • Record the count here: your Server A input token count.
  • Calculate the live difference by subtracting your Server A input token count from your two-server input token count.

You now have the amount of live input removed when Server B left the configuration.

  • Record the result here: your live input token difference.

You should see a lower input-token count in the one-server response. The difference measures the live input overhead removed with Server B.

Counts Don't Show a Clear Drop?

  • Confirm both tests used the same model.
  • Confirm each test started in a fresh conversation.
  • Confirm Server B was disconnected before the second message.

If the counts still look inconsistent, help me diagnose an MCP input-token comparison that did not decrease after disconnecting a server.

You have measured Server B's effect using real response data. Next, you will trim the exposed tool list and compare the cost before versus after.

Trim Tools and Chart Savings

Your previous test used the same short message with two server states. It proved that your connected Model Context Protocol (MCP) tools changed the input tokens attached to an identical request.

Your agent still needs the right tools for regular work. This step turns your measurements into a smaller configuration with a visible cost reduction.

In this step, get ready to:
  • Keep fewer than ten tools for regular work.
  • Export the complete trimmed tool definitions.
  • Build a before-and-after table from both cost reports.
Choose the tools you actually need

An allowlist names the only tools your agent can expose. Every retained tool should support a recurring task.

  • Switch back to the baseline tool list you printed before Server B was disconnected.
  • Identify the tools you use during regular work.
  • Capture the names of those tools here: your retained tool shortlist.
  • Limit your shortlist to no more than nine tools.

Why use an allowlist?

An allowlist prevents unused definitions from reaching the model on every turn. It also makes each retained tool an intentional choice.

  • Return to your agent's MCP configuration file from earlier.
  • Replace the current tool selection with your retained tool shortlist.
  • Reconnect Server B only when your shortlist includes one of its tools.
  • Leave Server B disconnected in every other case.
  • Save the MCP configuration file.
  • Reload the MCP configuration using the same method you used after disconnecting Server B.
  • Display the current exposed tool list using the same tool-list view from earlier.

You should see no more than nine exposed tools. Every visible tool should match your shortlist.

Still seeing extra tools?

Check whether a retained server exposes every tool by default. Apply your client's supported per-tool filtering control to that server.

Reload the configuration again if the client still shows definitions from its previous connection.

help me find why my MCP client still exposes tools that are missing from my allowlist.

Measure the trimmed export

A fair comparison uses the same export shape on both sides. The final export must contain every field that reaches the model.

What belongs in the final export?

Each exported definition must include the complete tool name.

Each definition must include its full description.

Each definition must include its complete input schema.

  • Return to the tool-definition export workflow from earlier.
  • Export the current complete definitions to mcp-tools-after.json.
  • Switch back to the code editor from earlier.
  • Open mcp-tools-after.json in the code editor.
  • Count the tool definitions in the exported file.
  • Capture the final count here: your final tool count.
  • Confirm that the final count is fewer than ten.

Your final count should match the exposed tool list in the agent. The file should contain definitions only for the retained tools.

  • Switch back to the local terminal from earlier.
  • Run the Step 3 measurement command against mcp-tools-after.json at the same recorded input-token rate.
  • Capture the printed token count here: your trimmed token count.
  • Capture the estimated cost here: your trimmed cost per turn.

You should see a trimmed token count with its estimated input cost per turn. These values form the After side of your comparison.

Does the trimmed count look too high?

Confirm that mcp-tools-after.json contains only the final exposed tools. Old definitions left in the file will inflate the result.

Check that you measured the After file with the same tokenizer settings used for mcp-tools-before.json.

help me diagnose why my trimmed MCP definition file still has a high token count.

Build the before-and-after table

The two reports become useful when their differences are visible in one place. Your table compares tool count, token count, and estimated input cost per turn.

  • Return to the notes containing your baseline cost report.
  • Add a four-column table to those notes.
  • Name the columns Metric, Before, After, and Reduction.

You should now see an empty comparison table beside the measurements you already recorded.

  • Add one row for each measured metric.
  • Populate the Before column from your baseline tool list and baseline cost report.

The Before column should now show the original tool count, baseline token count, and baseline cost per turn.

  • Enter your final tool count in the After cell for tool count.
  • Enter your trimmed token count in the After cell for token count.
  • Enter your trimmed cost per turn in the After cell for estimated cost per turn.
  • Calculate the reduction for every row.

Before the check, consider which metric you expect to show the clearest drop.

  • Verify that the After tool count is fewer than ten.
  • Compare the Before token count with the After token count.
  • Compare the Before cost per turn with the After cost per turn.

You should see a lower tool count in the After column. You should also see lower token usage and a lower estimated input cost per turn.

You have turned hidden context overhead into a number you can act on. Your agent now exposes only the tools that earn their place on every turn.

Secret mission

Run a Zero-Tool Control Test

Your comparison chart shows the savings from trimming. Run one controlled request with every MCP tool disabled to isolate the remaining tool-definition footprint. Restore the trimmed configuration when the comparison is complete.

Clean Up Your Resources

Clean Up Your Resources

The local project files create no ongoing cost while idle. Choose whether to keep the artifacts, pause your work, or delete the measurement files.

Resources you used:

  • mcp-tools-before.json and mcp-tools-after.json are local JSON exports containing the complete MCP tool definitions from before and after trimming.
  • measure_mcp_tool_cost.py is the reusable local Python script that calculates token counts and estimated input costs.

Keep everything running

Leave the setup intact if you plan to measure tool costs again. Your saved exports provide a baseline for future comparisons.

  • Keep the agent's trimmed configuration with fewer than ten exposed tools.
  • Leave Server B disconnected unless you need one of its intentionally retained tools.
  • Reuse measure_mcp_tool_cost.py whenever you add another server or tool.
  • Compare future results with the saved cost reports and before-and-after chart.

Pause - I'll come back to this later

Close your local tools to clear your workspace. The exported definitions and trimmed agent configuration remain ready for your return.

  • Close the local terminal from earlier.
  • Close the code editor from earlier.
  • Leave Server B disconnected while the project is paused.
  • Return to the saved files when you want to repeat the cost comparison.

Delete - I don't want to use this again

Deleting these files gives you a clean reset. Your trimmed MCP configuration stays untouched.

  • Return to the code editor from earlier.
  • Delete mcp-tools-before.json from the file sidebar.
  • Delete mcp-tools-after.json from the file sidebar.
  • Delete measure_mcp_tool_cost.py from the file sidebar.
  • Confirm that all three file names are gone from the file sidebar.
  • Keep Server B disconnected unless your regular work requires one of its tools.

Nice Work!

Nice Work!

Great work! You built a reusable cost audit for your Model Context Protocol tools. Your agent now exposes fewer than ten tools for regular work.

You've learned how to:

  • Capture a complete baseline of every tool definition in mcp-tools-before.json.
  • Use measure_mcp_tool_cost.py to calculate a token count. Apply your model's input rate to estimate the per-turn cost.
  • Prove the reduction with matching live test messages. Present the savings in a before-and-after chart after trimming the exposed list below ten tools.
  • Secret Mission: Complete the optional challenge to push your MCP measurement workflow further.

Ready to quiz yourself?