I have been reviewing my MCPs setup lately. Right now my most used ones are :

• Notion for journaling,
• TickTick for task and to do list management
• GitHub for handling issues while coding.

My main MCP client is OpenCode, and together these three cover most of my work and personal workflow.

Just got curious about what MCPs you guys use the most. Also open to suggestions if there are any other MCPs I should be trying out.

When I type something in the TUI and hit Enter, the text just disappears, but the message doesn't actually get sent.

This problem doesn't happen very often, but it's pretty frustrating when it does, especially when you're in the middle of something. There's No clear pattern to reproduce the problem. Restarting could fix it, but it might still happen after.

macOS, VSCode, zsh, v1.16.2.

https://github.com/anomalyco/opencode/issues/31217

https://reddit.com/link/1u1qt1a/video/8oov2m9pkd6h1/player

MCP is the best way to expose tools to LLM Agent, but the quality of the MCP tools' design can really impact the Agent's token and context window efficiency. I recently did some tests on two MCPs with identical functionalities. Turns out one of them has really bad performance. So I wanna share those bad MCP design patterns that cause this.

The Experiment

It all started when I wrote an MCP Server (MCP-A) for a to-do list app. It allows users to organize & create tasks, set due dates, add subtasks... Later, the app officially released its own MCP Server (MCP-B). Both MCPs have the same functionalities and hit the same backend API.

The experiment is set up as follows:

• Both MCP Servers connect to the same ToDo list account, and it will be reset after each test.
• I designed 40 test prompts to simulate typical use cases for these MCPs.
• I use the same model MiniMax-M2.7, the same system prompt, and the same Agent framework
• I use a MCP Evaluation Tool that I built: MCP-Eval. It runs a ReAct Agent on given prompts and uses LLM-as-Judge to examine whether each case was correctly completed, then summarizes the token usage and other performance metrics.

Here are the results:

| Metric              | MCP-A       | MCP-B       | Gap   |
| ------------------- | ----------- | ----------- | ----- |
| Tool Desc Length    | 11,464      | 3,682       | —     |
| Pass Rate           | 36/40 (90%) | 36/40 (90%) | Same  |
| Total input tokens  | 637,244     | 3,174,329   | 4.98× |
| Total output tokens | 17,301      | 23,238      | 1.34× |
| Total Agent steps   | 122         | 157         | 1.29× |
| Total time          | 597s        | 676s        | 1.13× |

In short, MCP-A ran faster, used less context window, and burned fewer tokens on the exact same tasks.

What makes the difference?

Bad MCP Design Cost Extra Agent Steps

The result shows that MCP-B took 35 more ReAct loops to complete 40 test cases compared to MCP-A, which means 30% more output token. I examined the log and found that the root cause is poor query tool design.

Take the `search tool` for example, its job is to find a todo item in the ToDo list. In MCP-B, this tool returns this:

{
  "id": "6a1916b48f08cb3a4c857ed0",
  "title": "buy some grocery",
  "url": "https://todo.example.com/tasks/6a1916b48f08cb3a4c857ed0"
}

But other CRUD operations require `project_id`, and `search_tool` doesn't return it. So the Agent has to call another tool `get_task_by_id` just to fill what's missing.

On the other hand, MCP-A's query_tasks returns all necessary info to perform the next action in a single call:

Task 1:
ID: 6a19143e8f084a8c8101612f
Title: buy some grocery
Project ID: 6a1914378f084a8c810160a9
Start Date: 2025-07-19 10:00:00
Priority: Medium
Status: Active

Unfiltered API Data was dumped into context window

MCP is the thin layer between regular APIs and LLMs. It returns API results to the Agent's context. If those results are passed through unprocessed, the Agent's context window will accumulate very fast.

Take MCP-B's `create_task` tool for example. Its job is to create a to-do item. This is what this tool returns:

{
  "id": "6a180de78f086bdead0608be",
  "projectId": "inbox125587327",
  "sortOrder": -39582418599936,
  "title": "buy some grocery",
  "content": null,
  "desc": null,
  "startDate": null,
  "dueDate": null,
  "timeZone": "Asia/Shanghai",
  "isAllDay": false,
  "priority": 0,
  "reminders": null,
  "repeatFlag": null,
  "completedTime": null,
  "status": 0,
  "items": null,
  "tags": [],
  "columnId": null,
  "parentId": null,
  "childIds": null,
  "columnName": null,
  "assignor": null,
  "etag": "ywmef11y",
  "kind": "TEXT",
  "createdTime": "2026-05-28T09:41:59+0000",
  "modifiedTime": "2026-05-28T09:41:59+0000",
  "focusSummaries": null
}

These 600+ characters mean nothing to the Agent's task, but are still dumped into the Agent's context.

On the other hand, MCP-A's create_tasks does a layer of filtering and formatting:

Task created successfully:

ID: 6a180a3d8f08b4cc4e2a331d
Title: buy some grocery
Project ID: 6a1805e28f08b4cc4e29be62
Task Timezone: Asia/Shanghai
Priority: None
Status: Active

This little tweak makes a huge difference in input token usage. The evaluation shows that MCP-B's return data makes each call 2.5× heavier than MCP-A's. And the gap will widen as the Agent session drags on.

Too many tools lead to harder decision-making

Another issue is tool count. More tools means a larger candidate set for the model to choose from, which directly increases decision difficulty. In MCP-A, 47 tools were compressed down to 14, covering the same functionality with fewer tools. The model picks the right one more often and wastes fewer rounds on retries.

In Summary

Based on this experiment, here are my takeaways on good MCP tool design:

Design Tools in a Chain

When designing a tool, think about what the Agent will need next, not just what it's asking for right now. Return enough context in the result so the Agent can take the next action without making another round-trip.

Keep Tools Orthogonal And Simple

Too many tools will increase the model's decision burden and the chance it picks the wrong one. So I think we should minimize the number of tools within an MCP while still covering the same functionality. Make sure they don't overlap functionalities.

For example, dissolve tool boundaries with parameters: create_tasks accepts single or batch input; query_tasks uses composable parameters like date_filter, project_id, priority, search_term to compress a dozen possible query tools into one.

Make Return Data LLM-Friendly

When your MCP returns data to the LLM, try to keep it simple and readable. You can filter out unnecessary fields from the API response and format the data in a way that's easier for the LLM to process, rather than passing through raw JSON as-is. This reduces the amount of text going into the context window. A single call might only save a few dozen tokens, but across repeated Agent loops, the impact on overall context usage compounds significantly.

---

All the tests above were run by MCP-Eval. It's an MCP Server benchmarking tool. If you want to check your MCP's performance, feel free to check this out.

https://github.com/Code-MonkeyZhang/mcp-eval

MCP is the best way to expose tools to LLM Agent, but the quality of the MCP tools' design can really impact the Agent's token and context window consumption. I recently did some tests on two MCPs with identical functionalities and wanna share some insights on building token-efficient MCP tools.

The Experiment

It all started when I wrote an MCP Server (MCP-A) for a to-do list app. It allows users to organize & create tasks, set due dates, add subtasks... Later, the app officially released its own MCP Server (MCP-B). Both MCPs have the same functionalities and hit the same backend API.

The experiment is set up as follows:

• Both MCP Servers connect to the same ToDo list account, and it will be reset after each test.
• I designed 40 test prompts to simulate typical use cases for these MCPs.
• I use the same model MiniMax-M2.7, the same system prompt, and the same Agent framework
• I use a MCP Evaluation Tool that I built: MCP-Eval. It runs a ReAct Agent on given prompts and uses LLM-as-Judge to examine whether each case was correctly completed, then summarizes the token usage and other performance metrics.

Here are the results:

| Metric              | MCP-A       | MCP-B       | Gap   |
| ------------------- | ----------- | ----------- | ----- |
| Tool Desc Length    | 11,464      | 3,682       | —     |
| Pass Rate           | 36/40 (90%) | 36/40 (90%) | Same  |
| Total input tokens  | 637,244     | 3,174,329   | 4.98× |
| Total output tokens | 17,301      | 23,238      | 1.34× |
| Total Agent steps   | 122         | 157         | 1.29× |
| Total time          | 597s        | 676s        | 1.13× |

In short, MCP-A ran faster, used less context window, and burned fewer tokens on the exact same tasks.

What makes the difference?

Bad MCP Design Cost Extra Agent Steps

The result shows that MCP-B took 35 more ReAct loops to complete 40 test cases compared to MCP-A, which means 30% more output token. I examined the log and found that the root cause is poor query tool design.

Take the `search tool` for example, its job is to find a todo item in the ToDo list. In MCP-B, this tool returns this:

{
  "id": "6a1916b48f08cb3a4c857ed0",
  "title": "buy some grocery",
  "url": "https://todo.example.com/tasks/6a1916b48f08cb3a4c857ed0"
}

But other CRUD operations require `project_id`, and `search_tool` doesn't return it. So the Agent has to call another tool `get_task_by_id` just to fill what's missing.

On the other hand, MCP-A's query_tasks returns all necessary info to perform the next action in a single call:

Task 1:
ID: 6a19143e8f084a8c8101612f
Title: buy some grocery
Project ID: 6a1914378f084a8c810160a9
Start Date: 2025-07-19 10:00:00
Priority: Medium
Status: Active

Unfiltered API Data was dumped into context window

MCP is the thin layer between regular APIs and LLMs. It returns API results to the Agent's context. If those results are passed through unprocessed, the Agent's context window will accumulate very fast.

accumulate

Take MCP-B's `create_task` tool for example. Its job is to create a to-do item. This is what this tool returns:

{
  "id": "6a180de78f086bdead0608be",
  "projectId": "inbox125587327",
  "sortOrder": -39582418599936,
  "title": "buy some grocery",
  "content": null,
  "desc": null,
  "startDate": null,
  "dueDate": null,
  "timeZone": "Asia/Shanghai",
  "isAllDay": false,
  "priority": 0,
  "reminders": null,
  "repeatFlag": null,
  "completedTime": null,
  "status": 0,
  "items": null,
  "tags": [],
  "columnId": null,
  "parentId": null,
  "childIds": null,
  "columnName": null,
  "assignor": null,
  "etag": "ywmef11y",
  "kind": "TEXT",
  "createdTime": "2026-05-28T09:41:59+0000",
  "modifiedTime": "2026-05-28T09:41:59+0000",
  "focusSummaries": null
}

These 600+ characters mean nothing to the Agent's task, but are still dumped into the Agent's context.

On the other hand, MCP-A's create_tasks does a layer of filtering and formatting:

Task created successfully:

ID: 6a180a3d8f08b4cc4e2a331d
Title: buy some grocery
Project ID: 6a1805e28f08b4cc4e29be62
Task Timezone: Asia/Shanghai
Priority: None
Status: Active

This little tweak makes a huge difference in input token usage. The evaluation shows that MCP-B's return data makes each call 5× heavier than MCP-A's. And the gap will widen as the Agent session drags on.

Too many tools lead to harder decision-making

Another issue is tool count. More tools means a larger candidate set for the model to choose from, which directly increases decision difficulty. In MCP-A, 47 tools were compressed down to 14, covering the same functionality with fewer tools. The model picks the right one more often and wastes fewer rounds on retries.

In Summary

Based on this experiment, here are my takeaways on good MCP tool design:

Design Tools in a Chain

When designing a tool, think about what the Agent will need next, not just what it's asking for right now. Return enough context in the result so the Agent can take the next action without making another round-trip.

Keep Tools Orthogonal And Simple

Too many tools will increase the model's decision burden and the chance it picks the wrong one. So I think we should minimize the number of tools within an MCP while still covering the same functionality. Make sure they don't overlap functionalities.

For example, dissolve tool boundaries with parameters: create_tasks accepts single or batch input; query_tasks uses composable parameters like date_filter, project_id, priority, search_term to compress a dozen possible query tools into one.

Make Return Data LLM-Friendly

When your MCP returns data to the LLM, try to keep it simple and readable. You can filter out unnecessary fields from the API response and format the data in a way that's easier for the LLM to process, rather than passing through raw JSON as-is. This reduces the amount of text going into the context window. A single call might only save a few dozen tokens, but across repeated Agent loops, the impact on overall context usage compounds significantly.

---

All the tests above were run by MCP-Eval. It's an MCP Server benchmarking tool. If you want to check your MCP's performance, feel free to check this out.

https://github.com/Code-MonkeyZhang/mcp-eval

MCP is the golden standard for LLM Agent tools, but the quality of MCP tools design can dramatically impact the Agent's token and context window consumption. I recently did some experiments on two MCP implementations with identical functionalities, and found that one of them has really bad performance compared to the other one on the exact same tasks

So I wanna share what I found from those experiments and some insights on building MCP tools that don't waste tokens.

The Experiment

It all started when I wrote an MCP Server (MCP-A) for a to-do list app. It allows users to organize & create tasks, set due dates, add subtasks... Later, the app officially released its own MCP Server (MCP-B). Both MCPs have the same functionalities and hit the same backend API.

The experiment is set up as follows:

• Both MCP Servers connect to the same ToDo list account, and it will be reset after each test.
• I designed 40 test prompts to simulate typical use cases for these MCPs.
• I use the same model MiniMax-M2.7, the same system prompt, and the same Agent framework
• I use a MCP Evaluation Tool that I built: MCP-Eval. It runs a ReAct Agent on given prompts and uses LLM-as-Judge to examine whether each case was correctly completed, then summarizes the token usage and other performance metrics.

The only variable is the MCP Servers. Everything else, like the LLM model, system prompts, and Harness, stays the same. Here are the results:

| Metric              | MCP-A       | MCP-B       | Gap   |
| ------------------- | ----------- | ----------- | ----- |
| Tool Desc Length    | 11,464      | 3,682       | —     |
| Pass Rate           | 36/40 (90%) | 36/40 (90%) | Same  |
| Total input tokens  | 637,244     | 3,174,329   | 4.98× |
| Total output tokens | 17,301      | 23,238      | 1.34× |
| Total Agent steps   | 122         | 157         | 1.29× |
| Total time          | 597s        | 676s        | 1.13× |

In short, MCP-A ran faster, used less context window, and burned fewer tokens on the exact same tasks.

What makes the difference?

Bad MCP Design Cost Extra Agent Steps

The result shows that MCP-B took 35 more ReAct loops to complete 40 test cases compared to MCP-A, which means 30% more output token. I examined the log and found that the root cause is poor query tool design.

Take the `search tool` for example, its job is to find a todo item in the ToDo list. In MCP-B, this tool returns this:

{
  "id": "6a1916b48f08cb3a4c857ed0",
  "title": "buy some grocery",
  "url": "https://todo.example.com/tasks/6a1916b48f08cb3a4c857ed0"
}

But other CRUD operations require `project_id`, and `search_tool` doesn't return it. So the Agent has to call another tool `get_task_by_id` just to fill what's missing.

On the other hand, MCP-A's query_tasks returns all necessary info to perform the next action in a single call:

Task 1:
ID: 6a19143e8f084a8c8101612f
Title: buy some grocery
Project ID: 6a1914378f084a8c810160a9
Start Date: 2025-07-19 10:00:00
Priority: Medium
Status: Active

Unfiltered Return Data costs more context window

MCP is the thin layer between regular APIs and LLMs. It returns API results to the Agent's context. If those results are passed through unprocessed, the Agent's context window will accumulates very fast.

accumulate

Take MCP-B's `create_task` tool for example. Its job is to create a to-do item. This is what this tool returns:

{
  "id": "6a180de78f086bdead0608be",
  "projectId": "inbox125587327",
  "sortOrder": -39582418599936,
  "title": "buy some grocery",
  "content": null,
  "desc": null,
  "startDate": null,
  "dueDate": null,
  "timeZone": "Asia/Shanghai",
  "isAllDay": false,
  "priority": 0,
  "reminders": null,
  "repeatFlag": null,
  "completedTime": null,
  "status": 0,
  "items": null,
  "tags": [],
  "columnId": null,
  "parentId": null,
  "childIds": null,
  "columnName": null,
  "assignor": null,
  "etag": "ywmef11y",
  "kind": "TEXT",
  "createdTime": "2026-05-28T09:41:59+0000",
  "modifiedTime": "2026-05-28T09:41:59+0000",
  "focusSummaries": null
}

These 600+ characters mean nothing to the Agent's task, but are still dumped into the Agent's context.

On the other hand, MCP-A's create_tasks does a layer of filtering and formatting:

Task created successfully:

ID: 6a180a3d8f08b4cc4e2a331d
Title: buy some grocery
Project ID: 6a1805e28f08b4cc4e29be62
Task Timezone: Asia/Shanghai
Priority: None
Status: Active

This little tweak makes a huge difference in input token usage for those MCPs. The evaluation shows that MCP-B's return data makes each call 5× heavier than MCP-A's. And the gap will widen as the Agent session drags on.

Too many tools lead to harder decision making

Another issue is tool count. More tools means a larger candidate set for the model to choose from, which directly increases decision difficulty. In MCP-A, 47 tools were compressed down to 14, covering the same functionality with fewer tools. The model picks the right one more often and wastes fewer rounds on retries.

In Summary

Based on this experiment, here are my takeaways on good MCP tool design:

Design Tools in a Chain

When designing a tool, think about what the Agent will need next, not just what it's asking for right now. Return enough context in the result so the Agent can take the next action without making another round-trip.

Keep Tools Orthogonal And Simple

Too many tools will increase the model's decision burden and the chance it picks the wrong one. So I think we should minimize the number of tools within an MCP while still covering the same functionality. Make sure they don't overlap functionalities.

For example, dissolve tool boundaries with parameters: create_tasks accepts single or batch input; query_tasks uses composable parameters like date_filter, project_id, priority, search_term to compress a dozen possible query tools into one.

Make Return Data LLM-Friendly

Don't pass through raw API JSON. Only return the fields the LLM needs, in readable, formatted text rather than JSON.

---

Thanks for reading this far.

BTW all the experiments above were run by MCP-Eval. If you want to check your MCP's performance, feel free to try it out.

https://github.com/Code-MonkeyZhang/mcp-eval

MCP is the golden standard for LLM Agent tools, but the quality of MCP tools design can dramatically impact the Agent's token and context window consumption. I recently did some experiments on two MCP implementations with identical functionalities, and found that one of them has really bad performance compared to the other one.

In this post, I wanna share what I found and give some insights on building MCP tools that don't waste tokens.

The Experiment:

It all started when I wrote an MCP Server (MCP-A) for a to-do list app. It allows users to organize & create tasks, set due dates, add subtasks... Later, the app officially released its own MCP Server (MCP-B). Both have identical functionalities and hit the same backend API.

The experiment is like this:

• Both MCP Servers connect to the same account.
• I designed 40 test prompts to simulate typical use cases for those MCPs.
• I use the same model MiniMax-M2.7, the same system prompt, and the same Agent framework
• I use a MCP Evaluation Tool that I built: MCP-Eval. It runs a ReAct Agent on given prompt sets and uses LLM-as-Judge to examine whether each case was correctly completed, then calculates the token usage and other performance metrics.

The only variable is the MCP Servers. Everything else stays the same. Here are the results:

| Metric              | MCP-A MCP   | MCP-B MCP   | Gap       |
| ------------------- | ----------- | ----------- | --------- |
| Tool Desc Length    | 11,464      | 3,682       | —         |
| Pass Rate           | 36/40 (90%) | 36/40 (90%) | Same      |
| Total input tokens  | 637,244     | 3,174,329   | 4.98×     |
| Total output tokens | 17,301      | 23,238      | 1.34×     |
| Total Agent steps   | 122         | 157         | 1.29×     |
| Total time          | 597s        | 676s        | 1.13×     |

In short, my MCP implementation (MCP-A) ran faster, used less context, and burned fewer tokens on the exact same tasks.

What makes the difference?

Poor Tool Design takes more Agent steps

MCP-B took 157 steps to complete 40 test cases, while MCP-A just took 122. The root cause is poor query tool design. MCP-B's tools return incomplete information, so the Agent has to make extra calls. Take the search tool for example, its job is to find a todo item in the ToDo list. In MCP-B, it only returns this:

{
  "id": "6a1916b48f08cb3a4c857ed0",
  "title": "buy some grocery",
  "url": "https://todo.example.com/tasks/6a1916b48f08cb3a4c857ed0"
}

But other tool operations like completing, deleting, or updating a task all need project_id, and search doesn't return it. So the Agent has to call get_task_by_id just to fill what's missing.

On the other hand, MCP-A's query_tasks returns complete information in a single call:

Task 1:
ID: 6a19143e8f084a8c8101612f
Title: buy some grocery
Project ID: 6a1914378f084a8c810160a9
Start Date: 2025-07-19 10:00:00
Priority: Medium
Status: Active

The Agent gets everything it needs in one shot. That's why it ran faster.

Another test case is where things really fell apart. The question asks to add subtasks to each task. MCP-A cleared it in 3 steps. MCP-B took 11 steps. That means it takes 4x steps for the Agent to land in the right place.

Return Data are Not Properly Filtered

MCP tools return their results to the Agent's context. If those results are passed through unprocessed, context accumulates very fast.

Take MCP-B's create_task for example. Its job is to create a to-do item. But instead of returning concise information, MCP-B dumps the entire backend JSON object:

{
  "id": "6a180de78f086bdead0608be",
  "projectId": "inbox125587327",
  "sortOrder": -39582418599936,
  "title": "buy some grocery",
  "content": null,
  "desc": null,
  "startDate": null,
  "dueDate": null,
  "timeZone": "Asia/Shanghai",
  "isAllDay": false,
  "priority": 0,
  "reminders": null,
  "repeatFlag": null,
  "completedTime": null,
  "status": 0,
  "items": null,
  "tags": [],
  "columnId": null,
  "parentId": null,
  "childIds": null,
  "columnName": null,
  "assignor": null,
  "etag": "ywmef11y",
  "kind": "TEXT",
  "createdTime": "2026-05-28T09:41:59+0000",
  "modifiedTime": "2026-05-28T09:41:59+0000",
  "focusSummaries": null
}

It has 600+ characters, and most of them mean nothing to the Agent, but are still dumped into the Agent's context.

On the other hand, MCP-A's create_tasks does a layer of filtering and formatting:

Task created successfully:

ID: 6a180a3d8f08b4cc4e2a331d
Title: buy some grocery
Project ID: 6a1805e28f08b4cc4e29be62
Task Timezone: Asia/Shanghai
Priority: None
Status: Active

This is the biggest driver of the input token gap. On average, MCP-B's return data makes each call 2.5× heavier than MCP-A's. The gap only widens as the session drags on.

There Are Too Many Tools:

Another factor is the tool description length. Every API call sends all tool descriptions into the context, and MCP-B has 47 tools vs MCP-A's 14.

| MCP-A  | MCP-B  |
| ------ | ------ |
| 14,159 | 54,221 |

That means at the first step, MCP-B's input tokens are already 3.8× that of MCP-A, and this is a fixed cost you pay on every single request.

In Summary

MCP-B's 5× cost input token gap comes down to three design problems:

• Tool chains aren't designed for how Agents actually use them: Tools don't hand off enough data to each other, forcing the Agent to make extra calls to fill in the blanks. Same task, 29% more steps.
• Return data is dumped into context unprocessed: Raw JSON with nulls and internal fields gets passed straight through, accumulating in the context window step after step.
• Redundant tool set: 47 tools where 14 would do. Every single API request carries the full schema overhead.

Based on this experiment, here are my takeaways on a good MCP Tool design:

Design tools in a chain:

When designing a tool, think about this: after the Agent gets this result, what's it most likely to do next? What additional information will it need? For example, with a search tool, after the Agent finds a task, it'll probably want to operate on it (complete, delete, update). So return associated fields like project_id along with the result. Don't make the Agent call a "get details" endpoint again. Every extra query is a full API round-trip, doubling the cost.

Keep tools orthogonal:

Don't provide tools with overlapping functionality. Among MCP-B's 47 tools, at least 10 are redundant: search and search_task take identical parameters and do the exact same thing; create_task is just batch_add_tasks with a single item;

MCP-A's approach is to dissolve tool boundaries with parameters: create_tasks accepts single or batch input; query_tasks uses composable parameters like date_filter, project_id, priority, search_term to compress a dozen possible query tools into one.

Make return data LLM-friendly:

Don't pass through raw API JSON. Only return the fields the LLM needs, in readable, formatted text rather than JSON.

---

Thanks for reading this far.

All the MCP experiments above were run by MCP-Eval. It's an MCP Server benchmarking tool. If you want to check your MCP's performance, feel free to check this out.

https://github.com/Code-MonkeyZhang/mcp-eval

and it's simple to use. You just need to provide:

• LLM API Key
• MCP Server configuration
• A set of test prompts

It will run the full evaluation on your MCP server for analysis. Hope this project could help you make your MCPs better.