{"id":20345,"date":"2026-07-15T16:45:43","date_gmt":"2026-07-15T16:45:43","guid":{"rendered":"https:\/\/www.comet.com\/site\/?p=20345"},"modified":"2026-07-15T18:24:33","modified_gmt":"2026-07-15T18:24:33","slug":"mcp-performance-optimization","status":"publish","type":"post","link":"https:\/\/www.comet.com\/site\/blog\/mcp-performance-optimization\/","title":{"rendered":"How We Optimized Opik\u2019s MCP Server for Cost & Performance"},"content":{"rendered":"\n

Like a lot of engineering teams, earlier this year we found ourselves hitting limits on AI token spend, trying to understand where those tokens were going and why, and how to manage cost without hurting performance. We ended up tackling this problem both internally, auditing and optimizing the coding agent configurations our team uses every day, and within our product, ensuring AI-powered features in Opik don\u2019t cost our customers more to run than they should. My colleague Collin wrote a great piece on those internal coding cost optimizations<\/a>, and in this post I\u2019ll dive deeper into our MCP server optimization process, which dramatically improved cost and performance for Opik users.<\/p>\n\n\n\n

\"\"<\/figure>\n\n\n\n

The MCP Optimization Problem: Tool Lists & Outdated REST Principles<\/h2>\n\n\n\n

Open the tool list of almost any MCP server and you\u2019ll find the underlying API restates one tool per endpoint. That\u2019s been the default recipe from the start, and even the biggest names in developer tooling follow it: GitHub\u2019s official server ships so many tools it needed a --toolsets<\/code> flag to switch groups of them off.<\/p>\n\n\n\n

\n

Ours was no different. The first MCP server for Opik, our LLM observability<\/a> platform, exposed about thirty tools \u2014 one per REST endpoint. Then we deleted nearly all of them. On purpose.<\/p>\n<\/blockquote>\n\n\n\n

None of those thirty tools was broken. The damage came from the list itself. A tool list doesn\u2019t just sit on the server waiting to be needed. It rides along in the context window<\/a> of every request, before the user has typed a word: names, descriptions, parameter schemas \u2014 all thirty tools, every time. Prompt caching makes re-sending that cheaper, but no smaller. The model still has to sift through all thirty schemas before every action, and with thirty near-identical names it picks the wrong tool more often than you\u2019d expect.<\/p>\n\n\n\n

Both problems are well documented \u2014 in Anthropic\u2019s guidance on tool selection and the MCPToolBench++ paper<\/a> \u2014 and the list only ever grew. Every new entity in the platform added another tool, and every tool claimed its slice of the context window, even when the job at hand had nothing to do with Opik.<\/p>\n\n\n\n

Imagine building your own agent and handing it thirty unfamiliar tools with every request. Before its reasoning ever reaches your question, it walks the whole list, deciding tool by tool whether any of it matters. It\u2019s stuck in the restaurant where the waiter recites thirty daily specials before taking your order on every visit, even though you always get the espresso.<\/p>\n\n\n\n

\n

So we rebuilt and optimized the MCP server around one rule: ship a shape the model can hold instead of mirroring the API. All of Opik\u2019s data management now fits in four tools. Three decisions made that possible.<\/p>\n<\/blockquote>\n\n\n\n

Decision 1: Four Tools Cover Everything<\/h2>\n\n\n\n

The first decision was to make the tool universal and the entity a parameter. list(entity)<\/code> browses any collection, filters it by name, and pages through the results. When a listing isn\u2019t enough, read(entity, id)<\/code> pulls up the full record.<\/p>\n\n\n\n

Writes work the same way. Every operation the platform supports is defined up front in a single registry\u2014entity.action<\/code> pairs like trace.create<\/code>, trace.update<\/code>, experiment.create<\/code>\u2014and a single write(operation, data)<\/code> executes any of them. The operation names form a closed enum, so the model still picks trace.create<\/code> by name; the signal of a named tool just lives one level down. And when it wants the exact payload shape, schema(operation)<\/code> hands it over on demand.<\/p>\n\n\n\n

The model learns the pattern once, and every piece of data in the platform is within reach of the same four tools.<\/p>\n\n\n\n

Decision 2: Self-Healing by Design<\/h2>\n\n\n\n

The second decision dealt with the risk a high-level interface carries: because the model doesn\u2019t see the full picture up front, it will sometimes guess a field or operation wrong. Here\u2019s a real exchange \u2014 one wrong field name:<\/p>\n\n\n\n

`write(\"score.create\", { \"target\": \"trace\", \"target_id\": \"019789d9-\u2026\",\"score_name\":\"helpfulness\", \"value\": 0.8 })`\n\n`{\n  \"error\": \"validation_failed\",\n  \"operation\": \"score.create\",\n  \"issues\": [\n     { \"field\": \"name\", \"message\": \"Field required\", \"code\":\"missing\" },\n     { \"field\": \"score_name\", \"message\": \"Extra inputs are not permitted\", \"code\":\"extra_forbidden\" }\n   ],\n   \"expected_schema\": { \"required\": [\"target\", \"target_id\", \"name\", \"value\"], \u2026 },\n   \"example\": { \"target\": \"trace\", \"target_id\": \"0193a300-\u2026\",\n   \"name\": \"helpfulness\", \"value\": 0.8, \"reason\": \"user-confirmed\" }\n}`<\/code><\/pre>\n\n\n\n
The rejection guides the model to the correct call, and the next one lands. That turns the risk into a feature: corrections arrive exactly when the model needs them, and nothing has to be explained in advance. Prevention matters less when recovery costs a single turn.<\/p>\n\n\n\n
Decision 3: Every Token Earns its Place<\/strong><\/h2>\n\n\n\n
The last MCP optimization decision is about what comes back. Observability data is heavy: a single RAG trace<\/a> can carry hundreds of spans, with full prompts and completions in their payloads. One raw return would undo everything the smaller surface saved. Here\u2019s how read<\/code> responds when a trace weighs in at about 131,000 tokens:<\/p>\n\n\n\n
[read: trace 019789d9-\u2026 | compression=SKELETON | 6,652 tok returned | 131,710 tok full]\n{\n\"trace\": { \"id\": \"019789d9-\u2026\", \"name\": \"rag.chat.completion\" },\n\"spans\": [\n{ \"id\": \"01970000-\u2026\", \"name\": \"retriever.search\", \"type\": \"tool\" },\n{ \"id\": \"01970001-\u2026\", \"name\": \"openai.chat\",      \"type\": \"llm\"  },\n\u2026 298 more \u2026\n],\n\"note\": \"SKELETON compression: payloads omitted. Use read('span', id) for details.\"\n}<\/code><\/pre>\n\n\n\n
The response sizes itself. Small results arrive whole. Bigger ones lose their long strings, and each cut leaves a breadcrumb to the full value. Giants collapse into a skeleton, and everything sheds noise on the way out: empty fields and verbose wrappers, gone.<\/p>\n\n\n\n
That\u2019s what the three decisions buy. Data management now scales as far as Opik can grow: a new entity is a registry entry, a new operation is an enum value, and four tools stay four. The model works through a high-level interface that covers every need and corrects it when it slips. And nobody has to worry about the context window anymore: it stays clean, and the tokens it holds go to answers.<\/p>\n\n\n\n
\n
If you\u2019re building an MCP<\/a> server, the hardest part is unlearning the REST principles we\u2019ve lived by for years. An LLM values different things: clean high-level abstractions and room to recover, because it learns from whatever comes back. Build the interface that teaches instead of the contract that punishes, and the waiter finally just brings the espresso.<\/p>\n<\/blockquote>\n\n\n\n
Next Steps in MCP Optimization & AI Spend Management<\/h2>\n\n\n\n
As our team worked to optimize our MCP server and reduce token waste both internally and in Opik, we saw a number of patterns emerge in terms of where our inflated Claude Code spend was going. It turned out that developers hitting limits weren\u2019t overusing Claude or being actively wasteful \u2014 in fact, they were able to save roughly 30% by managing context and configurations without losing any productivity.<\/p>\n\n\n\n
We realized teams needed better tooling to understand which skills, tools, MCPs, and default models were loading on every call, which ones cost the most, and whether their cost was justified by the output. This exercise led us to develop Cost Intelligence<\/a>, a tool that finds and fixes wasteful coding agent configurations at the developer, team, and org level \u2014 and keeps context bloat in check as environments grow and change.<\/p>\n\n\n\n
Optimize Coding Agent Spend with Comet Cost Intelligence<\/h3>\n\n\n\n
If your engineering team is facing similar challenges with AI spend management, we\u2019d love to share more of our optimization experience and set up a custom demo of Cost Intelligence, showing how much your team can save with one-click optimizations. Contact us<\/a> with some info about your team, coding environment, and goals and we\u2019ll help you track down wasted tokens and attribute spending to engineering outcomes.<\/p>\n","protected":false},"excerpt":{"rendered":"
Like a lot of engineering teams, earlier this year we found ourselves hitting limits on AI token spend, trying to understand where those tokens were going and why, and how to manage cost without hurting performance. We ended up tackling this problem both internally, auditing and optimizing the coding agent configurations our team uses every […]<\/p>\n","protected":false},"author":132,"featured_media":20346,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"customer_name":"","customer_description":"","customer_industry":"","customer_technologies":"","customer_logo":"","_jetpack_memberships_contains_paid_content":false,"footnotes":""},"categories":[10,65,7],"tags":[],"coauthors":[365],"class_list":["post-20345","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-industry","category-llmops","category-tutorials"],"yoast_head":"\nHow We Optimized Opik\u2019s MCP Server for Cost & Performance<\/title>\n<meta name=\"description\" content=\"These 3 architectural decisions helped us rebuild and optimize our product's MCP server to load fewer tools and improve performance.\" \/>\n<meta name=\"robots\" content=\"index, follow, max-snippet:-1, max-image-preview:large, max-video-preview:-1\" \/>\n<link rel=\"canonical\" href=\"https:\/\/www.comet.com\/site\/blog\/mcp-performance-optimization\/\" \/>\n<meta property=\"og:locale\" content=\"en_US\" \/>\n<meta property=\"og:type\" content=\"article\" \/>\n<meta property=\"og:title\" content=\"How We Optimized Opik\u2019s MCP Server for Cost & Performance\" \/>\n<meta property=\"og:description\" content=\"These 3 architectural decisions helped us rebuild and optimize our product's MCP server to load fewer tools and improve performance.\" \/>\n<meta property=\"og:url\" content=\"https:\/\/www.comet.com\/site\/blog\/mcp-performance-optimization\/\" \/>\n<meta property=\"og:site_name\" content=\"Comet\" \/>\n<meta property=\"article:publisher\" content=\"https:\/\/www.facebook.com\/cometdotml\" \/>\n<meta property=\"article:published_time\" content=\"2026-07-15T16:45:43+00:00\" \/>\n<meta property=\"article:modified_time\" content=\"2026-07-15T18:24:33+00:00\" \/>\n<meta property=\"og:image\" content=\"https:\/\/www.comet.com\/site\/wp-content\/uploads\/2026\/07\/MCP-server-optimization-1024x576.png\" \/>\n\t<meta property=\"og:image:width\" content=\"1024\" \/>\n\t<meta property=\"og:image:height\" content=\"576\" \/>\n\t<meta property=\"og:image:type\" content=\"image\/png\" \/>\n<meta name=\"author\" content=\"Yaroslav Boiko\" \/>\n<meta name=\"twitter:card\" content=\"summary_large_image\" \/>\n<meta name=\"twitter:creator\" content=\"@Cometml\" \/>\n<meta name=\"twitter:site\" content=\"@Cometml\" \/>\n<meta name=\"twitter:label1\" content=\"Written by\" \/>\n\t<meta name=\"twitter:data1\" content=\"Yaroslav Boiko\" \/>\n\t<meta name=\"twitter:label2\" content=\"Est. reading time\" \/>\n\t<meta name=\"twitter:data2\" content=\"5 minutes\" \/>\n<!-- \/ Yoast SEO Premium plugin. -->","yoast_head_json":{"title":"How We Optimized Opik\u2019s MCP Server for Cost & Performance","description":"These 3 architectural decisions helped us rebuild and optimize our product's MCP server to load fewer tools and improve performance.","robots":{"index":"index","follow":"follow","max-snippet":"max-snippet:-1","max-image-preview":"max-image-preview:large","max-video-preview":"max-video-preview:-1"},"canonical":"https:\/\/www.comet.com\/site\/blog\/mcp-performance-optimization\/","og_locale":"en_US","og_type":"article","og_title":"How We Optimized Opik\u2019s MCP Server for Cost & Performance","og_description":"These 3 architectural decisions helped us rebuild and optimize our product's MCP server to load fewer tools and improve performance.","og_url":"https:\/\/www.comet.com\/site\/blog\/mcp-performance-optimization\/","og_site_name":"Comet","article_publisher":"https:\/\/www.facebook.com\/cometdotml","article_published_time":"2026-07-15T16:45:43+00:00","article_modified_time":"2026-07-15T18:24:33+00:00","og_image":[{"width":1024,"height":576,"url":"https:\/\/www.comet.com\/site\/wp-content\/uploads\/2026\/07\/MCP-server-optimization-1024x576.png","type":"image\/png"}],"author":"Yaroslav Boiko","twitter_card":"summary_large_image","twitter_creator":"@Cometml","twitter_site":"@Cometml","twitter_misc":{"Written by":"Yaroslav Boiko","Est. reading time":"5 minutes"},"schema":{"@context":"https:\/\/schema.org","@graph":[{"@type":"Article","@id":"https:\/\/www.comet.com\/site\/blog\/mcp-performance-optimization\/#article","isPartOf":{"@id":"https:\/\/www.comet.com\/site\/blog\/mcp-performance-optimization\/"},"author":{"name":"Mike Ranellone","@id":"https:\/\/www.comet.com\/site\/#\/schema\/person\/b0df8d0db9a521af425e33f561b39c6a"},"headline":"How We Optimized Opik\u2019s MCP Server for Cost & Performance","datePublished":"2026-07-15T16:45:43+00:00","dateModified":"2026-07-15T18:24:33+00:00","mainEntityOfPage":{"@id":"https:\/\/www.comet.com\/site\/blog\/mcp-performance-optimization\/"},"wordCount":1145,"commentCount":0,"publisher":{"@id":"https:\/\/www.comet.com\/site\/#organization"},"image":{"@id":"https:\/\/www.comet.com\/site\/blog\/mcp-performance-optimization\/#primaryimage"},"thumbnailUrl":"https:\/\/www.comet.com\/site\/wp-content\/uploads\/2026\/07\/MCP-server-optimization-scaled.png","articleSection":["Industry","LLMOps","Tutorials"],"inLanguage":"en-US","potentialAction":[{"@type":"CommentAction","name":"Comment","target":["https:\/\/www.comet.com\/site\/blog\/mcp-performance-optimization\/#respond"]}]},{"@type":"WebPage","@id":"https:\/\/www.comet.com\/site\/blog\/mcp-performance-optimization\/","url":"https:\/\/www.comet.com\/site\/blog\/mcp-performance-optimization\/","name":"How We Optimized Opik\u2019s MCP Server for Cost & Performance","isPartOf":{"@id":"https:\/\/www.comet.com\/site\/#website"},"primaryImageOfPage":{"@id":"https:\/\/www.comet.com\/site\/blog\/mcp-performance-optimization\/#primaryimage"},"image":{"@id":"https:\/\/www.comet.com\/site\/blog\/mcp-performance-optimization\/#primaryimage"},"thumbnailUrl":"https:\/\/www.comet.com\/site\/wp-content\/uploads\/2026\/07\/MCP-server-optimization-scaled.png","datePublished":"2026-07-15T16:45:43+00:00","dateModified":"2026-07-15T18:24:33+00:00","description":"These 3 architectural decisions helped us rebuild and optimize our product's MCP server to load fewer tools and improve performance.","breadcrumb":{"@id":"https:\/\/www.comet.com\/site\/blog\/mcp-performance-optimization\/#breadcrumb"},"inLanguage":"en-US","potentialAction":[{"@type":"ReadAction","target":["https:\/\/www.comet.com\/site\/blog\/mcp-performance-optimization\/"]}]},{"@type":"ImageObject","inLanguage":"en-US","@id":"https:\/\/www.comet.com\/site\/blog\/mcp-performance-optimization\/#primaryimage","url":"https:\/\/www.comet.com\/site\/wp-content\/uploads\/2026\/07\/MCP-server-optimization-scaled.png","contentUrl":"https:\/\/www.comet.com\/site\/wp-content\/uploads\/2026\/07\/MCP-server-optimization-scaled.png","width":2560,"height":1440,"caption":"title card visualizing MCP server optimization at Comet"},{"@type":"BreadcrumbList","@id":"https:\/\/www.comet.com\/site\/blog\/mcp-performance-optimization\/#breadcrumb","itemListElement":[{"@type":"ListItem","position":1,"name":"Home","item":"https:\/\/www.comet.com\/site\/"},{"@type":"ListItem","position":2,"name":"How We Optimized Opik\u2019s MCP Server for Cost & Performance"}]},{"@type":"WebSite","@id":"https:\/\/www.comet.com\/site\/#website","url":"https:\/\/www.comet.com\/site\/","name":"Comet","description":"Build Better Models Faster","publisher":{"@id":"https:\/\/www.comet.com\/site\/#organization"},"potentialAction":[{"@type":"SearchAction","target":{"@type":"EntryPoint","urlTemplate":"https:\/\/www.comet.com\/site\/?s={search_term_string}"},"query-input":{"@type":"PropertyValueSpecification","valueRequired":true,"valueName":"search_term_string"}}],"inLanguage":"en-US"},{"@type":"Organization","@id":"https:\/\/www.comet.com\/site\/#organization","name":"Comet ML, Inc.","alternateName":"Comet","url":"https:\/\/www.comet.com\/site\/","logo":{"@type":"ImageObject","inLanguage":"en-US","@id":"https:\/\/www.comet.com\/site\/#\/schema\/logo\/image\/","url":"https:\/\/www.comet.com\/site\/wp-content\/uploads\/2025\/01\/logo_comet_square.png","contentUrl":"https:\/\/www.comet.com\/site\/wp-content\/uploads\/2025\/01\/logo_comet_square.png","width":310,"height":310,"caption":"Comet ML, Inc."},"image":{"@id":"https:\/\/www.comet.com\/site\/#\/schema\/logo\/image\/"},"sameAs":["https:\/\/www.facebook.com\/cometdotml","https:\/\/x.com\/Cometml","https:\/\/www.youtube.com\/channel\/UCmN63HKvfXSCS-UwVwmK8Hw"]},{"@type":"Person","@id":"https:\/\/www.comet.com\/site\/#\/schema\/person\/b0df8d0db9a521af425e33f561b39c6a","name":"Mike Ranellone","image":{"@type":"ImageObject","inLanguage":"en-US","@id":"https:\/\/www.comet.com\/site\/#\/schema\/person\/image\/47e0209bd037ec57787bae2b580d796f","url":"https:\/\/www.comet.com\/site\/wp-content\/uploads\/2026\/06\/cropped-mike-ranellone-96x96.jpg","contentUrl":"https:\/\/www.comet.com\/site\/wp-content\/uploads\/2026\/06\/cropped-mike-ranellone-96x96.jpg","caption":"Mike Ranellone"},"sameAs":["https:\/\/www.comet.com\/"],"url":"https:\/\/www.comet.com\/site\/blog\/author\/mikercomet-com\/"}]}},"jetpack_featured_media_url":"https:\/\/www.comet.com\/site\/wp-content\/uploads\/2026\/07\/MCP-server-optimization-scaled.png","jetpack_sharing_enabled":true,"_links":{"self":[{"href":"https:\/\/www.comet.com\/site\/wp-json\/wp\/v2\/posts\/20345","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.comet.com\/site\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.comet.com\/site\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.comet.com\/site\/wp-json\/wp\/v2\/users\/132"}],"replies":[{"embeddable":true,"href":"https:\/\/www.comet.com\/site\/wp-json\/wp\/v2\/comments?post=20345"}],"version-history":[{"count":3,"href":"https:\/\/www.comet.com\/site\/wp-json\/wp\/v2\/posts\/20345\/revisions"}],"predecessor-version":[{"id":20357,"href":"https:\/\/www.comet.com\/site\/wp-json\/wp\/v2\/posts\/20345\/revisions\/20357"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/www.comet.com\/site\/wp-json\/wp\/v2\/media\/20346"}],"wp:attachment":[{"href":"https:\/\/www.comet.com\/site\/wp-json\/wp\/v2\/media?parent=20345"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.comet.com\/site\/wp-json\/wp\/v2\/categories?post=20345"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.comet.com\/site\/wp-json\/wp\/v2\/tags?post=20345"},{"taxonomy":"author","embeddable":true,"href":"https:\/\/www.comet.com\/site\/wp-json\/wp\/v2\/coauthors?post=20345"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}