mcp

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries the full burden of behavioral disclosure. It describes the response format ('concise 2-4 sentence reply'), grounding ('grounded in Christian's published writing and autobiography'), and scope limitations. However, it doesn't mention potential limitations like rate limits, authentication needs, or error conditions.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is efficiently structured in two sentences: the first establishes purpose and scope, the second specifies response format and exclusions. Every phrase adds value with zero waste, making it easy for an agent to parse quickly.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a single-parameter Q&A tool with no annotations and no output schema, the description provides strong context about purpose, usage boundaries, and response characteristics. The main gap is the lack of output format details (structure, error cases), but given the tool's relative simplicity, the description is mostly complete.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the schema already documents the single 'question' parameter thoroughly. The description adds marginal value by reinforcing the topic boundaries mentioned in the schema description, but doesn't provide additional parameter semantics beyond what's already in the structured data.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's purpose: 'Ask Alti, Christian Perez's AI agent, a single question about Christian' with specific domains listed (work at Altivum, The Vector Podcast, his book, military service, AWS/Applied AI practice). It distinguishes from sibling tools (get_blog_post, search_blog) by focusing on Q&A about Christian rather than blog content retrieval.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides explicit usage guidance: 'Ask... a single question about Christian' with specific topic boundaries and a clear exclusion: 'Does NOT answer general knowledge questions.' This tells the agent exactly when to use this tool versus alternatives.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries the full burden of behavioral disclosure. It effectively describes the return format ('Returns title, publication date, tags, series, excerpt, and the full post body as plain text') and the operation's purpose. However, it doesn't mention potential error conditions, rate limits, or authentication requirements.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is perfectly concise with two sentences that each serve distinct purposes: the first defines the tool's function and output, the second provides usage guidance. There is no wasted language or redundancy.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple read operation with one parameter and no output schema, the description provides good context about what the tool returns and when to use it. However, without annotations or output schema, it could benefit from mentioning error handling or response format details.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the schema already fully documents the single 'slug' parameter. The description adds minimal value beyond what the schema provides, only reinforcing that the slug identifies the blog post. This meets the baseline for high schema coverage.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the specific action ('Retrieve the full text'), resource ('a single Christian Perez blog post'), and scope ('by slug'). It distinguishes from the sibling tool 'search_blog' by specifying this is for retrieving a known post rather than searching for one.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explicitly provides when to use this tool ('if you already know the slug') and when to use an alternative ('Use search_blog first if you don't already know the slug'). This gives clear guidance on tool selection between siblings.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries full burden and does well by disclosing key behavioral traits: result limit ('Returns up to 5 matching posts'), ordering ('ordered by relevance'), return format ('title, excerpt, and URL'), and relationship to sibling tool. It doesn't mention rate limits or authentication needs, but covers most essential behavior.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences with zero waste - first sentence covers purpose, scope, and return format; second sentence provides clear usage guidance. Perfectly front-loaded with all essential information in the first sentence.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a search tool with no annotations and no output schema, the description provides excellent context about what the tool does, how to use it, and what it returns. It could mention error conditions or authentication requirements, but covers the essential workflow and limitations well given the tool's complexity.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the schema already fully documents both parameters. The description adds minimal value beyond the schema - it mentions 'keyword or short phrase' which aligns with the query parameter description, but doesn't provide additional semantic context. Baseline 3 is appropriate when schema does the heavy lifting.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the specific action ('search'), target resource ('Christian Perez's blog on thechrisgrey.com'), and scope ('for posts matching a keyword or short phrase'). It distinguishes from sibling tool get_blog_post by explaining the relationship between them.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly states when to use this tool ('search for posts matching a keyword or short phrase') and when to use an alternative ('Use get_blog_post afterward to fetch the full body of a specific post by slug'). Provides clear context about the workflow between tools.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.