MCP工具设计优化：从数据搬运到洞察交付，提升上下文效率

1. 项目概述：当MCP工具成为“话痨”，你的Claude上下文预算正在被悄悄烧光

如果你正在开发或使用基于Claude的MCP工具，很可能正面临一个没人明说、却每天都在发生的资源浪费问题：上下文预算的无效消耗。想象一下这个场景：你向Claude提问，它调用了一个工具，工具返回了一大段未经处理的原始数据（比如500个token的JSON），Claude需要费力地读完、理解、总结，最终才给你一个简短的答案。这就像你让一位资深分析师去读三页纸的原始财报，只为了让他告诉你“今天股价跌了”这一句话。效率低得令人发指，而成本（在这里是宝贵的上下文长度）却高得惊人。

我在开发我的第一个MCP工具套件FinanceKit时，就亲手把这个错误设计进了架构里。工具忠实地从雅虎财经API拉取数据，原封不动地扔给Claude，然后看着Claude在回复中艰难地消化那些regularMarketDayHigh、trailingPE。直到我意识到，Claude调用工具后生成的回复质量时好时坏，且响应速度不稳定，我才开始深挖根源。问题不在于Claude的能力，而在于我喂给它的“饲料”太粗糙了。修复这个问题后，不仅工具响应的token数量平均减少了60%，Claude输出的分析质量、速度和确定性都得到了显著提升。这不仅仅是优化，这是一种设计范式的转变：MCP服务器不应仅仅是API的搬运工，而应该是为LLM推理引擎量身定制的“信息预处理厨房”。

本文将彻底拆解“上下文预算优化”这一核心议题。无论你是正在构建自己的MCP工具，还是希望更好地利用现有工具，理解并应用这些模式，都能让你在有限的上下文窗口内，获得更高质量、更快速的AI交互体验。我们将从问题本质出发，深入三个经过实战检验的设计模式，并提供可落地的测量方法与重构思路。

2. 问题根源：原始数据 ≠ 有效上下文

要解决问题，首先得看清问题的本质。一个典型的、未经优化的MCP工具响应是什么样的？让我们看一个股票报价工具的“反面教材”：

{ "symbol": "AAPL", "regularMarketPrice": 213.49, "regularMarketChange": -1.23, "regularMarketChangePercent": -0.57, "regularMarketVolume": 48293847, "regularMarketOpen": 214.20, "regularMarketDayHigh": 214.85, "regularMarketDayLow": 212.90, "fiftyTwoWeekHigh": 237.49, "fiftyTwoWeekLow": 164.08, "marketCap": 3214938472000, "trailingPE": 34.2, "forwardPE": 28.7, "dividendYield": 0.0051, "beta": 1.24, "averageVolume": 52847393, "averageVolume10days": 49827364, "currency": "USD", "exchange": "NMS", "quoteType": "EQUITY", // ... 可能还有更多字段 }

这段JSON包含了约20个字段，轻松超过500个token。对于人类开发者来说，这是一份结构清晰的数据；但对于Claude这样的LLM来说，它是一段需要被“阅读理解”的文本。Claude必须逐个token地扫描，识别出regularMarketChangePercent是涨跌幅，RSI（如果存在）是动量指标，marketCap是市值，然后再根据你的问题（例如“苹果股票现在表现如何？”）来综合这些信息，组织语言回答。

问题的严重性在于累积效应。单个工具调用浪费几百token或许可以忍受，但真实的用户对话往往是多步骤、多工具协作的。假设用户问：“我应该买入苹果股票吗？”一个朴素的Claude思考过程可能是：

1. 调用stock_quote工具，获取上述500+ token的原始数据。
2. 调用technical_analysis工具，获取另一份包含RSI、MACD、均线等数据的500+ token原始数据。
3. 调用risk_metrics工具，再获取一份关于波动率、夏普比率等的500+ token数据。

在Claude开始撰写第一句分析之前，它已经“阅读”了超过1500个token的原始数据。这些token本可以用于更深入的推理、更复杂的逻辑链条，或者支持更长的对话历史，但现在却被用于让LLM扮演一个“数据解析器”的角色。上下文预算正像沙漏中的沙子一样，在无声无息中流逝。

2.1 核心认知转变：Claude是推理引擎，不是数据解析器

这是优化工作最关键的思维转折点。我们习惯于将LLM视为“万能接口”，什么数据都丢给它，指望它自己搞定。但在MCP架构中，这种想法是低效的根源。Claude的核心优势在于基于已有信息进行逻辑推理、语言生成和复杂决策，而不是从一堆数字中提取基本事实。

你的服务器（或工具后端）拥有完整的计算能力、业务逻辑和对数据的深刻理解。它知道RSI=75意味着“超买”，price > 20日均线意味着“处于上升趋势”。为什么要把计算RSI > 70是否成立这个简单的布尔判断任务，连同几十个原始数据点一起，交给Claude，让它消耗上百个token去重新推导呢？应该由服务器完成“从数据到洞察”的第一次跃迁，然后将“洞察”而非“数据”提供给Claude进行二次推理。

这就好比你是经理，需要一份市场报告。低效的做法是让助理（Claude）去 raw database（API）里把所有的销售数字、日志条目都抄录下来，然后让他写报告。高效的做法是，你先让数据分析师（服务器）处理原始数据，生成一份带有关键结论、图表和摘要的PPT（结构化裁决），再把这份PPT交给助理，让他基于此撰写一份精炼的经理汇报。

3. 核心优化模式：从数据搬运到洞察交付

基于上述认知，我们可以推导出几种具体的设计模式。我在重构FinanceKit（金融分析工具包）和SiteAudit（网站审计工具包）时，主要应用了以下三种模式，它们具有普适性，可以移植到绝大多数MCP工具场景。

3.1 模式一：裁决字段 —— 提供结论，而非原料

这是最直接、最有效的优化手段。在工具的返回结构中，增加一个或多个预先计算好的“裁决”字段，直接告诉Claude当前的状态或建议。

优化前的技术分析工具响应（原始数据堆砌）：

{ "symbol": "AAPL", "rsi": 42.3, "macd": -0.15, "macd_signal": -0.08, "price": 213.49, "ma_20": 215.50, "ma_50": 210.80, // ... 更多指标 }

Claude需要解读：RSI 42.3属于中性偏弱，MACD为负且在信号线下方是看跌信号，价格低于20日均线但高于50日均线……综合得出“处于温和下跌趋势”的结论。

优化后的技术分析工具响应（包含裁决）：

{ "symbol": "AAPL", "price": 213.49, "change_pct": -0.57, "verdict": "NEUTRAL_TO_BEARISH", "signals": { "trend": "DOWNTREND — 价格连续3日低于20日均线", "momentum": "WEAKENING — RSI位于42，正接近超卖区域", "volume": "NORMAL — 成交量低于10日平均值8%", "risk": "MODERATE — Beta值1.24，位于52周区间37%分位" }, "one_line_summary": "AAPL处于温和下跌趋势，正在测试212美元支撑位。目前并非明确的买入时机。", "raw_metrics": { ... } // 完整的原始数据，仅在Claude明确需要时提供 }

实现解析与实操要点：在服务器端，你需要封装业务逻辑来判断状态。以Python为例，这通常是一系列清晰的规则：

def generate_verdict(rsi, macd_histogram, price, ma_20, ma_50): """根据技术指标生成裁决和信号。""" signals = [] verdict = "NEUTRAL" # 规则1: RSI判断 if rsi > 70: signals.append("OVERSOLD — RSI高于70，警惕回调风险") verdict = "BEARISH_Caution" if verdict == "NEUTRAL" else verdict elif rsi < 30: signals.append("OVERSOLD — RSI低于30，可能出现技术性反弹") verdict = "BULLISH_Opportunity" if verdict == "NEUTRAL" else verdict elif 30 <= rsi <= 70: signals.append(f"MOMENTUM_NEUTRAL — RSI位于{int(rsi)}，方向不明") # 规则2: 均线趋势判断 if price > ma_20 and price > ma_50: signals.append("UPTREND — 价格高于20日与50日均线，趋势向好") verdict = "BULLISH" elif price < ma_20 and price < ma_50: signals.append("DOWNTREND — 价格低于20日与50日均线，趋势向淡") verdict = "BEARISH" else: signals.append("CONSOLIDATION — 价格在均线间震荡，趋势不明") # 规则3: MACD判断 if macd_histogram > 0: signals.append("MOMENTUM_POSITIVE — MACD柱状图为正，动能转强") else: signals.append("MOMENTUM_NEGATIVE — MACD柱状图为负，动能转弱") # 生成一句话总结 if verdict.startswith("BULLISH"): one_line = f"{symbol}显示看涨信号，主要因{next((s for s in signals if 'UPTREND' in s), '积极动能')}。" elif verdict.startswith("BEARISH"): one_line = f"{symbol}面临压力，主要因{next((s for s in signals if 'DOWNTREND' in s), '动能减弱')}。建议观望。" else: one_line = f"{symbol}目前处于震荡格局，方向需等待更明确信号突破。" return { "verdict": verdict, "signals": signals, "one_line_summary": one_line }

实操心得：裁决字段的设计艺术

1. 语义化，而非编码化：verdict字段的值应该是像“STRONG_BUY”,“HOLD”,“SELL”,“NEUTRAL”,“CRITICAL_ERROR”这样LLM能直接理解并用于推理的单词或短语，而不是数字代码如1,2,3。
2. 信号分层：signals对象是一个黄金设计。它提供了裁决背后的关键论据，Claude可以引用它们来支撑其推理，而无需复述原始数据。每个信号应是一个完整的短语，如“HIGH_VOLUME — 成交量暴增200%”。
3. 保留原始数据通道：务必包含一个如raw_metrics的字段（或通过detail=full参数触发），但将其默认折叠或置于次要位置。这确保了在Claude需要进行深度、非常规分析时，仍有获取全部数据的能力。
4. 成本对比：一个“verdict: OVERSOLD”字段约消耗5-8个token。如果让Claude从{“rsi”: 75, “price”: 250, …}等几十个字段中自行推导出“超买”的结论，它可能需要消耗100-200个token进行内部“思考”和推导。前者效率高出1-2个数量级。

3.2 模式二：分层细节 —— 按需供给，默认精简

不是所有对话都需要所有数据。很多情况下，Claude或用户只需要一个高分摘要。分层细节模式允许工具根据请求的深度，返回不同信息密度的响应。

一个SEO审计工具的示例：

from typing import Literal from mcp import tool @tool() async def seo_audit(url: str, detail: Literal["summary", "full"] = "summary") -> dict: """ 对给定URL执行SEO审计。 默认使用 detail='summary' 以获取快速概览，节省上下文。 如需完整问题列表和详细数据，请使用 detail='full'。 """ # 模拟执行完整的、消耗资源的审计 full_results = await run_comprehensive_seo_scan(url) if detail == "summary": return { "url": url, "overall_score": full_results["score"], # e.g., 78/100 "grade": _score_to_grade(full_results["score"]), # e.g., "B+" "critical_issues_count": len([i for i in full_results["issues"] if i["severity"] == "critical"]), "top_recommendations": [ {"issue": issue["title"], "fix": issue["quick_fix"]} for issue in sorted(full_results["issues"], key=lambda x: x["severity_score"])[:2] # 仅返回最严重的2个 ], "message": f"网站整体健康度{full_results['score']}/100 ({_score_to_grade(full_results['score'])}). 发现{len(full_results['issues'])}个问题，其中{len([i for i in full_results['issues'] if i['severity'] == 'critical'])}个为关键问题。最急需修复的是：{full_results['issues'][0]['title']}" } else: # detail == "full" return full_results # 返回包含所有检查点、分数、描述、建议的完整报告（可能多达数千token）

工作流程解析：

1. 默认高效路径：当用户问“我的网站SEO怎么样？”，Claude会默认以detail=“summary”调用工具。工具返回一个包含总分、等级、关键问题数量和最紧急建议的浓缩版响应（约150-300 token）。Claude可以立即生成如“您的网站得分为B+，有两个关键问题需要优先处理：缺少meta描述和图片alt标签。”这样的回答。
2. 按需深度挖掘：如果用户追问“具体是哪些图片缺少alt标签？”，Claude可以在后续的工具调用中，指定detail=“full”，或者调用另一个更细粒度的工具（如get_image_seo_details）来获取详细信息。
3. Claude的智能调度：优秀的LLM如Claude能够理解detail参数的含义。在对话中，它会倾向于先使用summary模式获取概览，只有当对话逻辑或用户问题明确指向细节时，才会请求full数据。

注意事项与设计技巧

1. 参数命名清晰：使用像detail、granularity、verbosity这样意图明确的参数名，并配以良好的文档字符串，帮助Claude理解何时使用哪种模式。
2. “summary”必须真正有用：摘要不能只是数据的简单截取。它必须包含聚合（如总数、平均分）、分类（如按严重性分组的问题数）、排序（最严重/最重要的项）和可操作的结论。目标是让Claude仅凭摘要就能完成80%的对话任务。
3. 平衡计算开销：有时生成摘要本身需要额外计算。在设计时要评估：是每次调用都生成完整数据再提取摘要划算，还是实现两种独立的处理流程。通常，先生成完整数据再提取摘要更简单且一致。
4. 适用于列表型数据：此模式对返回列表（如问题列表、文章列表、产品列表）的工具尤其有效。默认返回前N个最重要的项及其摘要，而非全部。

3.3 模式三：预计算比较 —— 合并请求，服务器端对比

当用户的问题本质上是“比较A和B”时，最糟糕的做法是让Claude分别调用两次工具获取A和B的完整数据，然后在自己的上下文中执行比较逻辑。这浪费了两倍的上下文，且把本应由服务器高效完成的计算任务交给了LLM。

优化前的低效流程：

• 用户： “比较一下Python和JavaScript在数据科学项目中的优缺点。”
• Claude思考：我需要调用get_lang_info(‘python’)和get_lang_info(‘javascript’)。
• 结果：两个各400 token的响应，包含历史、语法、生态等方方面面。
• Claude行动：在上下文中对比这两个800 token的文档，费力地提取关于数据科学库、性能、学习曲线的异同点。

优化后的高效设计：一个专用的比较工具

@tool() async def compare_programming_languages(languages: list[str], aspect: str | None = None) -> dict: """ 比较多种编程语言在特定方面或综合方面的表现。 aspect: 可选，如 'data_science', 'web_dev', 'learning_curve'。如为None，则进行综合比较。 """ # 获取每种语言的详细数据（内部调用，不返回给Claude） all_data = [await _fetch_lang_data(lang) for lang in languages] # 服务器端执行比较逻辑 comparison_matrix = [] for data in all_data: row = { "language": data["name"], "summary_score": _calculate_composite_score(data, aspect), "key_strength": data["strengths"][0] if data["strengths"] else "N/A", "key_weakness": data["weaknesses"][0] if data["weaknesses"] else "N/A", } if aspect == "data_science": row["library_ecosystem"] = data["ecosystem"].get("data_science", "N/A") row["performance"] = data["performance"].get("numerical", "N/A") comparison_matrix.append(row) # 排序并生成裁决 ranked = sorted(comparison_matrix, key=lambda x: x["summary_score"], reverse=True) winner = ranked[0]["language"] # 生成比较结论 if aspect: reasoning = f"在'{aspect}'方面，{winner}因其{ranked[0].get('key_strength')}而领先。" else: reasoning = f"综合来看，{winner}在平衡性上最佳。{ranked[0]['language']}强于{ranked[0]['key_strength']}，但需注意{ranked[0]['key_weakness']}。" return { "aspect_comparison": aspect or "overall", "ranked_results": ranked, "winner": winner, "comparison_reasoning": reasoning, # 可选：提供一个简明的对比矩阵，供Claude快速引用 "quick_matrix": { lang["language"]: { "score": lang["summary_score"], "strength": lang["key_strength"], "weakness": lang["key_weakness"] } for lang in ranked } }

响应示例：

{ "aspect_comparison": "data_science", "ranked_results": [ { "language": "Python", "summary_score": 95, "key_strength": "庞大而成熟的数据科学生态系统（Pandas, NumPy, Scikit-learn, PyTorch）", "key_weakness": "在超高性能计算和浏览器端部署方面不如某些语言", "library_ecosystem": "Excellent", "performance": "Good" }, { "language": "JavaScript", "summary_score": 65, "key_strength": "强大的可视化库（D3.js, Chart.js）和Web集成能力", "key_weakness": "核心数据科学库相对较少，数值计算性能一般", "library_ecosystem": "Growing", "performance": "Fair" } ], "winner": "Python", "comparison_reasoning": "在'data_science'方面，Python因其庞大而成熟的数据科学生态系统（Pandas, NumPy, Scikit-learn, PyTorch）而领先。", "quick_matrix": { "Python": {"score": 95, "strength": "庞大而成熟的数据科学生态系统", "weakness": "超高性能计算和浏览器端部署"}, "JavaScript": {"score": 65, "strength": "强大的可视化库和Web集成能力", "weakness": "核心数据科学库较少"} } }

通过一次工具调用，Claude获得了一个已经排好序、有获胜者、有关键理由的对比结果。它可以直接引用winner和comparison_reasoning来组织答案，或者利用quick_matrix来展开论述。这比它自己处理两份原始数据要高效、准确得多。

设计要点与扩展

1. 识别比较场景：如果你的工具经常被用于A/B测试、产品选型、方案对比等场景，那么预计算比较模式是必须的。
2. 灵活的对比维度：通过aspect等参数，让工具能够进行多维度的比较。这比让Claude在庞杂的数据中自己筛选维度要高效。
3. 结构化对比结果：ranked_results（列表）和quick_matrix（字典）提供了不同粒度的信息。列表便于Claude进行顺序叙述，字典便于它进行属性对比。
4. 超越二元对比：该模式天然支持两个以上的对象比较，这是让Claude自行处理多个独立响应难以做到的。

4. 如何量化与评估你的优化效果

优化不能凭感觉，需要有简单的度量标准。我推荐一个叫做“信息密度比”的快速心算模型：

上下文效率 ≈ 有用洞察的数量 / 消耗的token总数

• 低效示例（原始数据模式）：一个股票报价工具返回了包含20个字段的500 token数据。对于“现在能买吗？”这个问题，Claude最终可能只从中提取出1个核心洞察（例如：“股价低于均线，趋势偏空”）。那么效率是1洞察 / 500 token = 0.002。
• 高效示例（裁决字段模式）：优化后的工具返回了150 token的数据，其中直接包含了verdict: “NEUTRAL_TO_BEARISH”、one_line_summary和几个关键的signals。Claude几乎无需处理原始数据就能获得2-3个可直接使用的洞察。效率是2.5洞察 / 150 token ≈ 0.017。

后者的上下文效率是前者的8倍以上。这意味着在同样的上下文窗口内，Claude可以进行更多轮的复杂推理和工具调用。

在设计新工具或重构旧工具时，我通常会问自己以下几个检查性问题：

1. 洞察可推导性：Claude能否不阅读全文，仅从响应中的某个或某几个字段就获得核心结论？如果不能，我是否需要增加一个summary或verdict字段？
2. 数据必要性：响应中的每个字段，在80%的调用场景中都是必需的吗？是否存在一些“以防万一”的字段（如原始请求ID、内部时间戳、冗长的调试信息）可以默认移除，或通过?verbose=true这样的参数来提供？
3. 工作流整合：这个工具是否总是一系列连续调用的中间步骤？例如，get_user_profile->get_user_orders->analyze_spending。如果是，能否创建一个复合工具analyze_user_financial_behavior(user_id)，直接返回包含画像、订单摘要和消费分析的综合结果？将三个各300 token的调用合并为一个500 token的调用，能显著提升效率。
4. LLM的认知负担：我返回的数据格式，是便于LLM理解的结构（如清晰的键名、枚举值、简短的描述字符串），还是更像给机器读的（如嵌套过深的数组、数字代码、缩写）？将“status”: 2改为“status”: “processing”，虽然多了几个字符，但为Claude省去了“状态码2代表什么？”的思考步骤。

5. 实战重构：从问题工具到高效工具的演变

让我们以一个虚构的“内容质量评估工具”为例，演示完整的重构过程。

原始版本（问题版本）：

@tool() async def assess_content(text: str) -> dict: """评估一段文本的内容质量。""" # 调用各种分析服务 readability_score = await calculate_flesch_kincaid(text) sentiment = await analyze_sentiment(text) keyword_density = await extract_keyword_density(text) grammar_errors = await check_grammar(text) return { "text_sample": text[:500], # 可能很大！ "readability_score": readability_score, # e.g., 65.4 "readability_grade_level": _score_to_grade(readability_score), # e.g., "8th-9th grade" "sentiment_score": sentiment["score"], # e.g., 0.78 "sentiment_label": sentiment["label"], # e.g., "positive" "top_keywords": keyword_density, # e.g., [{"word": "AI", "density": 0.05}, ...] "grammar_error_count": len(grammar_errors), "grammar_errors": grammar_errors, # 列表，可能很长 "word_count": len(text.split()), "sentence_count": len(text.split('.')), # ... 更多原始指标 }

问题诊断：这个响应可能轻松超过1000 token。text_sample可能很大，grammar_errors可能很长，top_keywords可能包含大量条目。Claude需要消化所有这些来回答“这篇文章写得怎么样？”

重构后版本（应用三大模式）：

from typing import Literal from mcp import tool @tool() async def assess_content_v2( text: str, detail: Literal["brief", "standard", "full"] = "standard", include_sample: bool = False ) -> dict: """ 评估文本内容质量，提供分层级的详细报告。 - brief: 仅总体评分和建议。 - standard: (默认) 包含关键维度的评分和主要问题。 - full: 包含所有详细数据和发现。 - include_sample: 是否在响应中包含文本样本（会增加token消耗）。 """ # 内部计算所有指标（与之前相同） readability_score = await calculate_flesch_kincaid(text) sentiment = await analyze_sentiment(text) keyword_density_list = await extract_keyword_density(text) grammar_errors = await check_grammar(text) # ... 可能还有其他分析 # --- 核心：服务器端生成洞察和裁决 --- overall_verdict = "GOOD" primary_concerns = [] recommendations = [] # 规则1: 可读性裁决 if readability_score < 50: overall_verdict = "NEEDS_IMPROVEMENT" primary_concerns.append("可读性较低，目标读者可能难以理解。") recommendations.append("尝试使用更短的句子和更常见的词汇。") elif readability_score > 80: recommendations.append("可读性极佳，适合大众阅读。") # 规则2: 语法裁决 error_count = len(grammar_errors) if error_count > 5: overall_verdict = "NEEDS_IMPROVEMENT" primary_concerns.append(f"发现{error_count}处语法错误，影响专业性。") recommendations.append("建议使用语法检查工具进行校对。") elif error_count > 0: primary_concerns.append(f"有{error_count}处轻微语法错误。") # 规则3: 关键词裁决 top_3_keywords = [kw["word"] for kw in keyword_density_list[:3]] if len(top_3_keywords) < 2: primary_concerns.append("核心关键词不够突出，可能影响主题明确性。") # 规则4: 情感裁决 if sentiment["label"] == "negative" and "critique" not in text.lower(): recommendations.append("整体情感偏负面，如果是说明文请确保论点客观。") # --- 根据detail参数构建响应 --- response = { "overall_verdict": overall_verdict, "quality_score": _compute_overall_score(readability_score, error_count, sentiment["score"]), # e.g., 78/100 } if detail in ["standard", "full"]: response.update({ "dimension_scores": { "readability": {"score": readability_score, "grade": _score_to_grade(readability_score)}, "grammar": {"score": 100 - min(error_count * 5, 100), "error_count": error_count}, "sentiment": {"label": sentiment["label"], "score": sentiment["score"]}, "keyword_focus": {"top_keywords": top_3_keywords} }, "primary_concerns": primary_concerns[:3], # 最多3条 "top_recommendations": recommendations[:2], # 最多2条 }) if detail == "full": response.update({ "detailed_metrics": { "full_readability_breakdown": {...}, "all_keyword_density": keyword_density_list, "grammar_error_details": grammar_errors[:10] # 限制数量 } }) if include_sample: response["text_sample"] = text[:200] # 只取前200字符 # 始终包含一个一句话总结，这是Claude最可能直接引用的部分 response["one_line_summary"] = _generate_one_line_summary( overall_verdict, response.get("quality_score", 0), primary_concerns ) return response

重构后的响应示例（detail=”standard”）:

{ "overall_verdict": "NEEDS_IMPROVEMENT", "quality_score": 62, "one_line_summary": "内容质量中等偏下（62分），主要问题在于可读性较低且存在多处语法错误，建议优先修改。", "dimension_scores": { "readability": {"score": 45, "grade": "College graduate level"}, "grammar": {"score": 70, "error_count": 6}, "sentiment": {"label": "neutral", "score": 0.05}, "keyword_focus": {"top_keywords": ["AI", "context", "token"]} }, "primary_concerns": [ "可读性较低，目标读者可能难以理解。", "发现6处语法错误，影响专业性。" ], "top_recommendations": [ "尝试使用更短的句子和更常见的词汇。", "建议使用语法检查工具进行校对。" ] }

这个响应大约在200-300 token之间，但包含了Claude生成高质量反馈所需的所有核心信息：总体裁决、分数、一句话总结、分维度评分、主要问题和建议。Claude可以直接组织语言：“根据评估，您的文本质量有待提高（62分）。主要问题有两个：一是可读性较低，相当于大学毕业生阅读水平；二是存在6处语法错误。建议您简化句子并做一次语法校对。” 这比让它从1000+ token的原始数据中自己总结要快得多、准得多。

6. 常见陷阱与进阶考量

在应用这些模式时，需要注意以下几个常见问题：

陷阱一：过度抽象，丢失必要细节优化不是一味地删减。有些场景下，原始数据就是必要的。例如，一个“数据可视化”工具需要返回准确的坐标数据；一个“代码执行”工具需要返回完整的输出或错误信息。关键是要区分“用于推理的上下文”和“用于执行的输出”。对于后者，可以考虑将其放在一个独立的字段（如execution_output）中，或者通过一个专门的get_raw_data工具来获取。

陷阱二：裁决逻辑过于武断或僵化服务器端的裁决逻辑是基于规则的，可能无法覆盖所有边缘情况或用户的特殊意图。因此：

1. 提供置信度：在裁决字段旁增加一个confidence分数（如0.8），让Claude知道这个结论的确定程度。
2. 保留原始数据访问路径：正如之前提到的，通过detail=“full”或?include_raw=true参数，确保在需要时能获取到全部信息。
3. 让裁决可解释：signals或primary_concerns字段本身就是解释。它们说明了裁决的依据，允许Claude在必要时质疑或细化这些依据。

陷阱三：忽视工具描述（Prompt）的优化MCP工具的功能描述（即传递给Claude的description）至关重要。优化后的工具，其描述也应该同步更新，以引导Claude正确使用。

• 旧描述：“获取股票的实时报价和市场数据。”
• 新描述：“获取股票的综合分析，包括当前价格、涨跌幅、技术面裁决（如超买/超卖）和关键信号。默认返回精简摘要，如需完整原始数据请指定detail=‘full’。适用于快速评估和投资决策支持。”清晰的描述能帮助Claude理解何时调用这个工具，以及如何使用参数。

进阶考量：动态上下文预算感知未来的MCP服务器或许可以更智能。它可以接收来自Claude的当前上下文剩余长度提示，并动态调整响应粒度。例如，如果剩余上下文很短，工具可以自动返回最精简的brief模式；如果上下文充裕，则返回更详细的standard模式。这需要协议层面的支持，但是一个值得思考的方向。

7. 总结与核心要义

经过对FinanceKit和SiteAudit的重构实践，我深刻体会到，在AI Agent架构中，上下文预算是一种比API速率限制更珍贵、更直接制约最终用户体验的资源。每一次不必要的token消耗，都在侵蚀Agent进行深度思考和多步规划的能力。

优化的核心哲学很简单：让你的服务器做它最擅长的事（数据处理、逻辑计算、业务规则判断），让LLM做它最擅长的事（语言理解、推理、生成和复杂决策）。通过提供裁决而非数据、摘要而非全集、对比结论而非并列事实，你将工具从“数据管道”升级为“智能副驾驶”。

这种设计转变带来的收益是立竿见影的：

1. 更低的延迟：Claude处理更短的响应，生成答案更快。
2. 更高的输出质量：Claude将更多“脑力”用于组织回答和深入推理，而非解析数据，回答通常更果断、更相关。
3. 更长的对话可能性：节省的上下文空间可以用于保留更长的历史对话，使Agent具有更好的记忆力和连贯性。
4. 更低的成本：对于按token计费的模型，直接降低了每次工具调用的成本。

最终，这不仅仅是技术优化，更是产品思维的体现。你设计的不是一个冰冷的API端点，而是一个与强大AI思维模型协同工作的认知接口。每一次工具调用，都应该是为Claude的思考过程注入高纯度的“思维燃料”，而非倾倒未经处理的“信息矿石”。当你开始用这种视角审视你的MCP工具时，你就会发现无处不在的优化机会，而每一次优化，都将直接提升你的AI应用最终用户的体验。