tool-design

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

Tool Design for Agents

Agent工具设计

Design every tool as a contract between a deterministic system and a non-deterministic agent. Unlike human-facing APIs, agent-facing tools must make the contract unambiguous through the description alone -- agents infer intent from descriptions and generate calls that must match expected formats. Every ambiguity becomes a potential failure mode that no amount of prompt engineering can fix.

将每个工具设计为确定性系统与非确定性Agent之间的契约。与面向人类的API不同，面向Agent的工具必须仅通过描述就让契约清晰明确——Agent会从描述中推断意图，并生成符合预期格式的调用。任何模糊性都会成为潜在的故障模式，而这类故障无法通过提示词工程来修复。

When to Activate

激活场景

Activate this skill when:

Creating new tools for agent systems
Debugging tool-related failures or misuse
Optimizing existing tool sets for better agent performance
Designing tool APIs from scratch
Evaluating third-party tools for agent integration
Standardizing tool conventions across a codebase

在以下场景中激活本技能：

为Agent系统创建新工具
调试与工具相关的故障或误用问题
优化现有工具集以提升Agent性能
从零开始设计工具API
评估第三方工具以进行Agent集成
在代码库中统一工具规范

Core Concepts

核心概念

Design tools around the consolidation principle: if a human engineer cannot definitively say which tool should be used in a given situation, an agent cannot be expected to do better. Reduce the tool set until each tool has one unambiguous purpose, because agents select tools by comparing descriptions and any overlap introduces selection errors.

Treat every tool description as prompt engineering that shapes agent behavior. The description is not documentation for humans -- it is injected into the agent's context and directly steers reasoning. Write descriptions that answer what the tool does, when to use it, and what it returns, because these three questions are exactly what agents evaluate during tool selection.

围绕整合原则设计工具：如果人类工程师无法明确判断在特定场景下应使用哪个工具，那么也不能指望Agent做得更好。精简工具集，直到每个工具都有唯一明确的用途，因为Agent是通过比较描述来选择工具的，任何功能重叠都会导致选择错误。

将每个工具描述视为能塑造Agent行为的提示词工程。描述不是给人类看的文档——它会被注入到Agent的上下文中，直接引导推理过程。描述需要回答工具的功能、使用场景以及返回结果，因为这三个问题正是Agent在选择工具时会评估的内容。

Detailed Topics

详细主题

The Tool-Agent Interface

Agent-工具接口

Tools as Contracts Design each tool as a self-contained contract. When humans call APIs, they read docs, understand conventions, and make appropriate requests. Agents must infer the entire contract from a single description block. Make the contract unambiguous by including format examples, expected patterns, and explicit constraints. Omit nothing that a caller needs to know, because agents cannot ask clarifying questions before making a call.

Tool Description as Prompt Write tool descriptions knowing they load directly into agent context and collectively steer behavior. A vague description like "Search the database" with cryptic parameter names forces the agent to guess -- and guessing produces incorrect calls. Instead, include usage context, parameter format examples, and sensible defaults. Every word in the description either helps or hurts tool selection accuracy.

Namespacing and Organization Namespace tools under common prefixes as the collection grows, because agents benefit from hierarchical grouping. When an agent needs database operations, it routes to the

db_*

namespace; when it needs web interactions, it routes to

web_*

. Without namespacing, agents must evaluate every tool in a flat list, which degrades selection accuracy as the count grows.

工具即契约 将每个工具设计为独立的契约。人类调用API时会阅读文档、理解规范并发起合适的请求。而Agent必须从单个描述块中推断出完整的契约。通过包含格式示例、预期模式和明确约束，让契约清晰明确。不要遗漏调用者需要知道的任何信息，因为Agent在发起调用前无法提出澄清问题。

工具描述即提示词 撰写工具描述时，要明确它们会直接加载到Agent上下文中，并共同引导Agent行为。像“搜索数据库”这样模糊的描述加上晦涩的参数名，会迫使Agent去猜测——而猜测会产生错误的调用。相反，应包含使用场景、参数格式示例和合理的默认值。描述中的每一个词都会影响工具选择的准确性。

命名空间与组织 随着工具集的扩大，使用通用前缀为工具设置命名空间，因为Agent能从分层分组中获益。当Agent需要数据库操作时，它会转向

db_*

命名空间；当需要Web交互时，会转向

web_*

命名空间。如果没有命名空间，Agent必须在扁平列表中评估所有工具，随着工具数量增加，选择准确性会下降。

The Consolidation Principle

整合原则

Single Comprehensive Tools Build single comprehensive tools instead of multiple narrow tools that overlap. Rather than implementing

list_users

list_events

, and

create_event

separately, implement

schedule_event

that finds availability and schedules in one call. The comprehensive tool handles the full workflow internally, removing the agent's burden of chaining calls in the correct order.

Why Consolidation Works Apply consolidation because agents have limited context and attention. Each tool in the collection competes for attention during tool selection, each description consumes context budget tokens, and overlapping functionality creates ambiguity. Consolidation eliminates redundant descriptions, removes selection ambiguity, and shrinks the effective tool set. Vercel demonstrated this principle by reducing their agent from 17 specialized tools to 2 general-purpose tools and achieving better performance -- fewer tools meant less confusion and more reliable tool selection.

When Not to Consolidate Keep tools separate when they have fundamentally different behaviors, serve different contexts, or must be callable independently. Over-consolidation creates a different problem: a single tool with too many parameters and modes becomes hard for agents to parameterize correctly.

单一综合工具 构建单一的综合工具，而非多个功能重叠的窄工具。不要分别实现

list_users

、

list_events

和

create_event

，而是实现一个能查找可用时间并完成调度的

schedule_event

工具。综合工具会在内部处理完整工作流，消除Agent按正确顺序链式调用工具的负担。

整合为何有效 应用整合原则是因为Agent的上下文和注意力有限。工具集中的每个工具都会在选择过程中争夺注意力，每个描述都会消耗上下文预算令牌，功能重叠则会造成模糊性。整合消除了冗余描述，避免了选择模糊性，并缩小了有效工具集的规模。Vercel通过将Agent的17个专用工具精简为2个通用工具，证明了这一原则的有效性——更少的工具意味着更少的混淆和更可靠的工具选择。

无需整合的场景 当工具具有根本不同的行为、服务于不同的上下文，或者必须能被独立调用时，应保持工具的独立性。过度整合会带来另一个问题：单个工具包含过多参数和模式，会让Agent难以正确设置参数。

Architectural Reduction

架构简化

Push the consolidation principle to its logical extreme by removing most specialized tools in favor of primitive, general-purpose capabilities. Production evidence shows this approach can outperform sophisticated multi-tool architectures.

The File System Agent Pattern Provide direct file system access through a single command execution tool instead of building custom tools for data exploration, schema lookup, and query validation. The agent uses standard Unix utilities (grep, cat, find, ls) to explore and operate on the system. This works because file systems are a proven abstraction that models understand deeply, standard tools have predictable behavior, agents can chain primitives flexibly rather than being constrained to predefined workflows, and good documentation in files replaces summarization tools.

When Reduction Outperforms Complexity Choose reduction when the data layer is well-documented and consistently structured, the model has sufficient reasoning capability, specialized tools were constraining rather than enabling the model, or more time is spent maintaining scaffolding than improving outcomes. Avoid reduction when underlying data is messy or poorly documented, the domain requires specialized knowledge the model lacks, safety constraints must limit agent actions, or operations genuinely benefit from structured workflows.

Build for Future Models Design minimal architectures that benefit from model improvements rather than sophisticated architectures that lock in current limitations. Ask whether each tool enables new capabilities or constrains reasoning the model could handle on its own -- tools built as "guardrails" often become liabilities as models improve.

See Architectural Reduction Case Study for production evidence.

将整合原则推向极致，移除大多数专用工具，转而使用原始的通用功能。生产实践表明，这种方法的性能可能优于复杂的多工具架构。

文件系统Agent模式 通过单个命令执行工具提供直接的文件系统访问，而非为数据探索、架构查找和查询验证构建自定义工具。Agent使用标准Unix工具（grep、cat、find、ls）来探索和操作系统。这种模式之所以有效，是因为文件系统是模型深度理解的成熟抽象，标准工具的行为可预测，Agent能灵活地链式调用原语，而不受预定义工作流的限制，同时文件中的良好文档可以替代摘要工具。

简化优于复杂的场景 当数据层文档完善、结构一致，模型具备足够的推理能力，专用工具限制而非赋能模型，或者维护脚手架的时间多于优化结果的时间时，选择简化架构。当底层数据混乱或文档不全、领域需要模型缺乏的专业知识、安全约束必须限制Agent的操作，或者操作确实能从结构化工作流中获益时，避免使用简化架构。

为未来模型设计 设计能从模型改进中获益的极简架构，而非锁定当前局限性的复杂架构。要思考每个工具是能启用新功能，还是会限制模型本身可以处理的推理——作为“护栏”构建的工具，往往会随着模型的改进而成为负担。

查看架构简化案例研究获取生产实践证据。

Tool Description Engineering

工具描述工程

Description Structure Structure every tool description to answer four questions:

What does the tool do? State exactly what the tool accomplishes -- avoid vague language like "helps with" or "can be used for."
When should it be used? Specify direct triggers ("User asks about pricing") and indirect signals ("Need current market rates").
What inputs does it accept? Describe each parameter with types, constraints, defaults, and format examples.
What does it return? Document the output format, structure, successful response examples, and error conditions.

Default Parameter Selection Set defaults to reflect common use cases. Defaults reduce agent burden by eliminating unnecessary parameter specification and prevent errors from omitted parameters. Choose defaults that produce useful results without requiring the agent to understand every option.

描述结构 每个工具描述都应结构化，以回答四个问题：

工具的功能是什么？准确说明工具能完成的任务——避免使用“有助于”或“可用于”这类模糊语言。
何时使用该工具？明确直接触发场景（“用户询问定价”）和间接信号（“需要当前市场价格”）。
工具接受哪些输入？描述每个参数的类型、约束、默认值和格式示例。
工具返回什么？记录输出格式、结构、成功响应示例和错误情况。

默认参数选择 设置默认值以反映常见用例。默认值通过消除不必要的参数指定，减轻Agent的负担，并防止因参数遗漏导致的错误。选择无需Agent了解所有选项就能产生有用结果的默认值。

Response Format Optimization

响应格式优化

Offer response format options (concise vs. detailed) because tool response size significantly impacts context usage. Concise format returns essential fields only, suitable for confirmations. Detailed format returns complete objects, suitable when full context drives decisions. Document when to use each format in the tool description so agents learn to select appropriately.

提供响应格式选项（简洁版 vs 详细版），因为工具响应的大小会显著影响上下文的使用。简洁版仅返回必要字段，适用于确认场景。详细版返回完整对象，适用于需要完整上下文驱动决策的场景。在工具描述中记录每种格式的使用场景，让Agent学会正确选择。

Error Message Design

错误消息设计

Design error messages for two audiences: developers debugging issues and agents recovering from failures. For agents, every error message must be actionable -- it must state what went wrong and how to correct it. Include retry guidance for retryable errors, corrected format examples for input errors, and specific missing fields for incomplete requests. An error that says only "failed" provides zero recovery signal.

为两类受众设计错误消息：调试问题的开发人员和从故障中恢复的Agent。对于Agent，每条错误消息都必须具备可操作性——必须说明出错的原因以及如何纠正。对于可重试的错误，包含重试指导；对于输入错误，包含修正后的格式示例；对于不完整的请求，包含具体缺失的字段。仅显示“失败”的错误消息无法提供任何恢复信号。

Tool Definition Schema

工具定义 Schema

Establish a consistent schema across all tools. Use verb-noun pattern for tool names (

get_customer

create_order

), consistent parameter names across tools (always

customer_id

, never sometimes

id

and sometimes

identifier

), and consistent return field names. Consistency reduces the cognitive load on agents and improves cross-tool generalization.

在所有工具中建立一致的Schema。工具名称使用动词-名词模式（

get_customer

、

create_order

），工具间使用一致的参数名称（始终使用

customer_id

，不要有时用

id

有时用

identifier

），以及一致的返回字段名称。一致性能减轻Agent的认知负担，提升跨工具的泛化能力。

Tool Collection Design

工具集设计

Limit tool collections to 10-20 tools for most applications, because research shows description overlap causes model confusion and more tools do not always lead to better outcomes. When more tools are genuinely needed, use namespacing to create logical groupings. Implement selection mechanisms: tool grouping by domain, example-based selection hints, and umbrella tools that route to specialized sub-tools.

对于大多数应用，将工具集限制在10-20个工具以内，因为研究表明描述重叠会导致模型混淆，更多工具并不总能带来更好的结果。当确实需要更多工具时，使用命名空间创建逻辑分组。实现选择机制：按领域分组工具、基于示例的选择提示，以及能路由到专用子工具的总括工具。

MCP Tool Naming Requirements

MCP工具命名要求

Always use fully qualified tool names with MCP (Model Context Protocol) to avoid "tool not found" errors.

Format:

ServerName:tool_name

python

undefined

始终使用带有MCP（Model Context Protocol）的完全限定工具名称，以避免“工具未找到”错误。

格式：

ServerName:tool_name

python

undefined

Correct: Fully qualified names

正确：完全限定名称

"Use the BigQuery:bigquery_schema tool to retrieve table schemas." "Use the GitHub:create_issue tool to create issues."

Incorrect: Unqualified names

错误：非限定名称

"Use the bigquery_schema tool..." # May fail with multiple servers


Without the server prefix, agents may fail to locate tools when multiple MCP servers are available. Establish naming conventions that include server context in all tool references.

"Use the bigquery_schema tool..." # 多服务器环境下可能失败


如果没有服务器前缀，当存在多个MCP服务器时，Agent可能无法定位工具。建立包含服务器上下文的命名规范，并在所有工具引用中遵循该规范。

Using Agents to Optimize Tools

使用Agent优化工具

Feed observed tool failures back to an agent to diagnose issues and improve descriptions. Production testing shows this approach achieves 40% reduction in task completion time by helping future agents avoid mistakes.

The Tool-Testing Agent Pattern:

python

def optimize_tool_description(tool_spec, failure_examples):
    """
    Use an agent to analyze tool failures and improve descriptions.

    Process:
    1. Agent attempts to use tool across diverse tasks
    2. Collect failure modes and friction points
    3. Agent analyzes failures and proposes improvements
    4. Test improved descriptions against same tasks
    """
    prompt = f"""
    Analyze this tool specification and the observed failures.

    Tool: {tool_spec}

    Failures observed:
    {failure_examples}

    Identify:
    1. Why agents are failing with this tool
    2. What information is missing from the description
    3. What ambiguities cause incorrect usage

    Propose an improved tool description that addresses these issues.
    """

    return get_agent_response(prompt)

This creates a feedback loop: agents using tools generate failure data, which agents then use to improve tool descriptions, which reduces future failures.

将观察到的工具故障反馈给Agent，以诊断问题并改进描述。生产测试表明，这种方法能将任务完成时间缩短40%，帮助未来的Agent避免犯错。

工具测试Agent模式:

python

def optimize_tool_description(tool_spec, failure_examples):
    """
    Use an agent to analyze tool failures and improve descriptions.

    Process:
    1. Agent attempts to use tool across diverse tasks
    2. Collect failure modes and friction points
    3. Agent analyzes failures and proposes improvements
    4. Test improved descriptions against same tasks
    """
    prompt = f"""
    Analyze this tool specification and the observed failures.

    Tool: {tool_spec}

    Failures observed:
    {failure_examples}

    Identify:
    1. Why agents are failing with this tool
    2. What information is missing from the description
    3. What ambiguities cause incorrect usage

    Propose an improved tool description that addresses these issues.
    """

    return get_agent_response(prompt)

这会形成一个反馈循环：使用工具的Agent生成故障数据，然后Agent利用这些数据改进工具描述，从而减少未来的故障。

Testing Tool Design

测试工具设计

Evaluate tool designs against five criteria: unambiguity, completeness, recoverability, efficiency, and consistency. Test by presenting representative agent requests and evaluating the resulting tool calls against expected behavior.

根据五个标准评估工具设计：明确性、完整性、可恢复性、效率和一致性。通过呈现代表性的Agent请求，并评估生成的工具调用是否符合预期行为来进行测试。

Practical Guidance

实践指南

Tool Selection Framework

工具选择框架

When designing tool collections:

Identify distinct workflows agents must accomplish
Group related actions into comprehensive tools
Ensure each tool has a clear, unambiguous purpose
Document error cases and recovery paths
Test with actual agent interactions

设计工具集时：

确定Agent必须完成的不同工作流
将相关操作分组为综合工具
确保每个工具都有清晰明确的用途
记录错误场景和恢复路径
通过实际Agent交互进行测试

Examples

示例

Example 1: Well-Designed Tool

python

def get_customer(customer_id: str, format: str = "concise"):
    """
    Retrieve customer information by ID.

    Use when:
    - User asks about specific customer details
    - Need customer context for decision-making
    - Verifying customer identity

    Args:
        customer_id: Format "CUST-######" (e.g., "CUST-000001")
        format: "concise" for key fields, "detailed" for complete record

    Returns:
        Customer object with requested fields

    Errors:
        NOT_FOUND: Customer ID not found
        INVALID_FORMAT: ID must match CUST-###### pattern
    """

Example 2: Poor Tool Design

This example demonstrates several tool design anti-patterns:

python

def search(query):
    """Search the database."""
    pass

Problems with this design:

Vague name: "search" is ambiguous - search what, for what purpose?
Missing parameters: What database? What format should query take?
No return description: What does this function return? A list? A string? Error handling?
No usage context: When should an agent use this versus other tools?
No error handling: What happens if the database is unavailable?

Failure modes:

Agents may call this tool when they should use a more specific tool
Agents cannot determine correct query format
Agents cannot interpret results
Agents cannot recover from failures

示例1：设计良好的工具

python

def get_customer(customer_id: str, format: str = "concise"):
    """
    根据ID检索客户信息。

    使用场景：
    - 用户询问特定客户的详细信息
    - 决策时需要客户上下文
    - 验证客户身份

    参数：
        customer_id：格式为"CUST-######"（例如："CUST-000001"）
        format："concise"表示仅返回关键字段，"detailed"表示返回完整记录

    返回：
        包含请求字段的客户对象

    错误：
        NOT_FOUND：客户ID不存在
        INVALID_FORMAT：ID必须符合CUST-######格式
    """

示例2：设计糟糕的工具

本示例展示了几种工具设计反模式：

python

def search(query):
    """Search the database."""
    pass

该设计的问题：

名称模糊："search"含义模糊——搜索什么，用于什么目的？
缺少参数说明：哪个数据库？查询应采用什么格式？
缺少返回描述：该函数返回什么？列表？字符串？错误处理机制？
缺少使用场景：Agent何时应使用此工具而非其他工具？
缺少错误处理：数据库不可用时会发生什么？

故障模式：

Agent可能在应使用更专用工具时调用此工具
Agent无法确定正确的查询格式
Agent无法解释结果
Agent无法从故障中恢复

Guidelines

准则

Write descriptions that answer what, when, and what returns
Use consolidation to reduce ambiguity
Implement response format options for token efficiency
Design error messages for agent recovery
Establish and follow consistent naming conventions
Limit tool count and use namespacing for organization
Test tool designs with actual agent interactions
Iterate based on observed failure modes
Question whether each tool enables or constrains the model
Prefer primitive, general-purpose tools over specialized wrappers
Invest in documentation quality over tooling sophistication
Build minimal architectures that benefit from model improvements

撰写能回答功能、使用场景和返回结果的描述
使用整合原则减少模糊性
实现响应格式选项以提升令牌效率
为Agent恢复设计错误消息
建立并遵循一致的命名规范
限制工具数量并使用命名空间进行组织
通过实际Agent交互测试工具设计
根据观察到的故障模式进行迭代
质疑每个工具是赋能还是限制模型
优先选择原始通用工具而非专用包装器
投入文档质量而非工具复杂度
构建能从模型改进中获益的极简架构

Gotchas

注意事项

Vague descriptions: Descriptions like "Search the database for customer information" leave too many questions unanswered. State the exact database, query format, and return shape.
Cryptic parameter names: Parameters named
```
x
```
,
```
val
```
, or
```
param1
```
force agents to guess meaning. Use descriptive names that convey purpose without reading further documentation.
Missing error recovery guidance: Tools that fail with generic messages like "Error occurred" provide no recovery signal. Every error response must tell the agent what went wrong and what to try next.
Inconsistent naming across tools: Using
```
id
```
in one tool,
```
identifier
```
in another, and
```
customer_id
```
in a third creates confusion. Standardize parameter names across the entire tool collection.
MCP namespace collisions: When multiple MCP tool providers register tools with similar names (e.g., two servers both exposing
```
search
```
), agents cannot disambiguate. Always use fully qualified
```
ServerName:tool_name
```
format and audit for collisions when adding new providers.
Tool description rot: Descriptions become inaccurate as underlying APIs evolve -- parameters get added, return formats change, error codes shift. Treat descriptions as code: version them, review them during API changes, and test them against current behavior.
Over-consolidation: Making a single tool handle too many workflows produces parameter lists so large that agents struggle to select the right combination. If a tool requires more than 8-10 parameters or serves fundamentally different use cases, split it.
Parameter explosion: Too many optional parameters overwhelm agent decision-making. Each parameter the agent must evaluate adds cognitive load. Provide sensible defaults, group related options into format presets, and move rarely-used parameters into an
```
options
```
object.
Missing error context: Error messages that say only "failed" or "invalid input" without specifying which input, why it failed, or what a valid input looks like leave agents unable to self-correct. Include the invalid value, the expected format, and a concrete example in every error response.

模糊描述：像“在数据库中搜索客户信息”这样的描述留下太多未解答的问题。应明确说明具体数据库、查询格式和返回结构。
晦涩的参数名：命名为
```
x
```
、
```
val
```
或
```
param1
```
的参数会迫使Agent猜测含义。使用无需进一步阅读文档就能传达用途的描述性名称。
缺少错误恢复指导：仅返回“发生错误”的通用消息无法提供恢复信号。每条错误响应都必须告诉Agent出错的原因以及下一步应尝试的操作。
工具间命名不一致：在一个工具中使用
```
id
```
，另一个中使用
```
identifier
```
，第三个中使用
```
customer_id
```
会造成混淆。在整个工具集中标准化参数名称。
MCP命名空间冲突：当多个MCP工具提供商注册名称相似的工具时（例如，两个服务器都暴露
```
search
```
工具），Agent无法区分。始终使用
```
ServerName:tool_name
```
的完全限定格式，并在添加新提供商时检查冲突。
工具描述过时：随着底层API的演进，描述会变得不准确——参数被添加、返回格式改变、错误代码更新。将描述视为代码：进行版本控制，在API变更时审核，并针对当前行为进行测试。
过度整合：让单个工具处理过多工作流会导致参数列表过长，Agent难以选择正确的组合。如果一个工具需要8-10个以上的参数，或服务于根本不同的用例，应将其拆分。
参数爆炸：过多可选参数会让Agent的决策过程不堪重负。Agent必须评估的每个参数都会增加认知负担。提供合理的默认值，将相关选项分组为格式预设，并将很少使用的参数移至
```
options
```
对象中。
缺少错误上下文：仅显示“失败”或“无效输入”的错误消息，而不指定哪个输入无效、失败原因或有效输入的示例，会让Agent无法自我纠正。在每条错误响应中包含无效值、预期格式和具体示例。

Integration

集成

This skill connects to:

context-fundamentals - How tools interact with context
multi-agent-patterns - Specialized tools per agent
evaluation - Evaluating tool effectiveness

本技能与以下技能相关联：

context-fundamentals - 工具与上下文的交互方式
multi-agent-patterns - 为每个Agent配备专用工具
evaluation - 评估工具的有效性

References

参考资料

Internal references:

Best Practices Reference - Read when: designing a new tool from scratch or auditing an existing tool collection for quality gaps
Architectural Reduction Case Study - Read when: considering removing specialized tools in favor of primitives, or evaluating whether a complex tool architecture is justified

Related skills in this collection:

context-fundamentals - Tool context interactions
evaluation - Tool testing patterns

External resources:

MCP (Model Context Protocol) documentation - Read when: implementing tools for multi-server agent environments or debugging tool routing failures
Framework tool conventions - Read when: adopting a new agent framework and need to map tool design principles to framework-specific APIs
API design best practices for agents - Read when: translating existing human-facing APIs into agent-facing tool interfaces
Vercel d0 agent architecture case study - Read when: evaluating whether to consolidate tools or seeking production evidence for architectural reduction

内部参考：

最佳实践参考 - 适用场景：从零开始设计新工具，或审核现有工具集的质量差距
架构简化案例研究 - 适用场景：考虑移除专用工具转而使用原语，或评估复杂工具架构是否合理

本套件中的相关技能：

context-fundamentals - 工具上下文交互
evaluation - 工具测试模式

外部资源：

MCP（Model Context Protocol）文档 - 适用场景：为多服务器Agent环境实现工具，或调试工具路由故障
框架工具规范 - 适用场景：采用新的Agent框架，需要将工具设计原则映射到框架特定的API
Agent专用API设计最佳实践 - 适用场景：将现有面向人类的API转换为面向Agent的工具接口
Vercel d0 Agent架构案例研究 - 适用场景：评估是否要整合工具，或寻找架构简化的生产实践证据

Skill Metadata

技能元数据

Created: 2025-12-20 Last Updated: 2026-03-17 Author: Agent Skills for Context Engineering Contributors Version: 2.0.0

创建时间：2025-12-20 最后更新时间：2026-03-17 作者：上下文工程Agent技能贡献者版本：2.0.0