Walnai Website MCP

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

The description discloses that a lead notification flow is triggered after a valid estimate, which is a key side effect. No annotations exist, so the description carries the burden. However, it does not detail permissions, reversibility, or whether the estimate is stored. Adequate but not thorough.

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?

Three sentences, front-loaded with purpose, then inputs, then outcome. No wasted words, but the misleading second sentence detracts slightly. Efficient overall.

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?

Given the complexity (nested objects, many parameters, no output schema, no annotations), the description is incomplete. It does not explain error handling, output format, or the inconsistency with the schema's required fields. Missing critical details for correct usage.

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?

The schema has 100% coverage with a description for the request object, so the tool description adds marginal value. It reinforces the 'exactly one service input' concept, but contradicts the schema's required field list, potentially misleading. Thus, no bonus beyond baseline.

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 it calculates a Walnai pricing estimate and triggers a lead notification. The verb 'calculates' and resource 'pricing estimate' are specific. However, the mention of 'exactly one service input object' could cause confusion with the schema, but overall purpose is clear.

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?

No guidance on when to use this tool vs alternatives like 'get_pricing' or 'submit_lead'. The description implies it's for generating estimates with lead capture, but does not explain trade-offs or scenarios.

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?

No annotations are provided, so the description carries full burden. While 'Gets' implies a read operation, the description doesn't disclose any behavioral traits like authentication requirements, rate limits, response format, or whether this is a public API. It only states what information is returned, not how the operation behaves.

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 a single, well-structured sentence that efficiently communicates the tool's purpose. It's front-loaded with the main action and provides specific details about what information is retrieved. Every word earns its place with no wasted text.

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 zero-parameter informational tool with no annotations and no output schema, the description provides adequate but minimal context. It explains what information is retrieved but doesn't address format, structure, or behavioral aspects. Given the simplicity of the tool (no parameters), this is acceptable but leaves gaps in understanding the full operation.

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?

With 0 parameters and 100% schema description coverage, the baseline would be 4. The description appropriately doesn't discuss parameters since none exist, and the schema already documents this completely. No additional parameter information is needed or provided.

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 with a specific verb ('Gets') and resource ('information about Walnai'), including scope details ('who they are, what they do, and why organizations choose them'). It distinguishes from some siblings like get_pricing or list_services, but doesn't explicitly differentiate from get_who_is_walnai which appears similar.

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 no guidance on when to use this tool versus alternatives. With siblings like get_who_is_walnai that seem potentially overlapping, there's no indication of when this tool is appropriate versus when to use other informational tools on the server.

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 for behavioral disclosure. While 'Gets' implies a read-only operation, it doesn't explicitly state this or describe any behavioral traits like authentication requirements, rate limits, error conditions, or response format. The description mentions what information is returned but not how it's structured or any limitations.

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 a single, efficient sentence that front-loads the core purpose. It wastes no words on unnecessary details while clearly communicating what the tool does. However, it could be slightly more structured by explicitly separating the different types of details retrieved.

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 read operation with no parameters, no annotations, and no output schema, the description is incomplete. It doesn't explain what format the adoption details are returned in, whether there are any access restrictions, or what happens if the information isn't available. The agent lacks sufficient context to use this tool effectively beyond the basic purpose.

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?

The tool has 0 parameters with 100% schema description coverage (empty schema), so the baseline is 4. The description appropriately doesn't discuss parameters since none exist, and it doesn't need to compensate for any schema gaps. This is the correct approach for a parameterless tool.

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 with a specific verb ('Gets') and resource ('Walnai's AI adoption process details'), including what information it retrieves (phases, integration capabilities, support model). It distinguishes itself from siblings like 'get_about_info' or 'get_service_details' by focusing specifically on adoption process details. However, it doesn't explicitly contrast with all siblings, so it doesn't reach the highest score.

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 no guidance on when to use this tool versus alternatives. It doesn't mention when this tool is appropriate, what prerequisites might exist, or how it differs from similar tools like 'get_service_details' or 'list_services'. The agent must infer usage context from the tool name and description alone.

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?

While the description implies a read-only informational nature, it does not explicitly state behavioral traits such as non-destructiveness, rate limits, or authentication requirements. With no annotations, the description carries the full burden but only hints at safety.

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 a single sentence that front-loads the purpose and includes specific details (AIO, structured content, etc.) without wasted words.

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 tool with no output schema, the description should specify the return format. It only says 'answers... and explains...', leaving the structure of the response ambiguous. The list of subtopics helps but is not fully 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?

There are zero parameters, so baseline is 4. The description adds meaning by explaining what the tool returns (answers about discoverability roles and methods), which is valuable beyond the empty schema.

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 uses specific verbs 'answers' and 'explains' to clearly indicate the tool provides information about AI discoverability, distinguishing it from sibling tools like 'get_about_info' or 'get_who_is_walnai'.

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 does not provide any guidance on when to use this tool versus alternatives, nor does it mention prerequisites or context for use. The agent must infer usage from the tool name alone.

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?

No annotations are provided, so the description carries the full burden. It discloses the null return case and the inclusion of HTML body, which adds behavioral context beyond the input schema. However, it doesn't mention any potential side effects or authentication, but for a read-only operation this is acceptable.

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 maximum information density – front-loaded with the core action and resource, followed by usage guidance and edge-case behavior. No redundant words.

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?

Given the simplicity of the tool (one parameter, no output schema, no nested objects), the description fully covers what an agent needs: what it does, how to use it correctly (list first), and what happens on missing input.

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 coverage is 100% with a clear description for the 'slug' parameter. The tool description adds context about discovering slugs via list_blog_posts, but does not add new semantic details about the parameter itself beyond the schema. Baseline 3 is appropriate.

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 uses a specific verb ('Gets') and resource ('full Walnai blog post by its slug'), and clearly distinguishes itself from siblings like 'list_blog_posts' which only lists slugs.

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 recommends using 'ListBlogPosts first to discover available slugs' and notes return behavior ('Returns null if the slug is not found'), giving clear when-to-use and alternative orientation.

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?

No annotations are provided, so the description carries the full burden of behavioral disclosure. The description mentions this is for 'lead-capture guidance' but doesn't specify whether this is a read-only operation, what format the guidance comes in, whether it requires authentication, or if there are rate limits. For a tool with zero annotation coverage, this leaves significant behavioral gaps.

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 a single, well-constructed sentence that efficiently communicates the tool's purpose, resource, and usage context. Every word serves a purpose with no wasted language, making it appropriately sized and front-loaded.

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?

Given the tool has no parameters, no output schema, and no annotations, the description provides adequate basic information about what the tool does and when to use it. However, it doesn't specify what format the 'guidance' comes in or how it should be used in AI chats, leaving some contextual gaps for the agent.

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?

The tool has 0 parameters with 100% schema description coverage, so the baseline is 4. The description appropriately doesn't discuss parameters since none exist, and instead focuses on the tool's purpose and usage context.

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: 'Gets the recommended Walnai lead-capture guidance to use in AI chats after sharing service, pricing, FAQ, adoption, or company information.' It specifies the verb ('Gets') and resource ('recommended Walnai lead-capture guidance'), and provides context about when it's used ('after sharing service, pricing, FAQ, adoption, or company information'). However, it doesn't explicitly differentiate from sibling tools like 'submit_lead' which might handle actual lead submission.

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 clear context for when to use this tool: 'after sharing service, pricing, FAQ, adoption, or company information.' This gives the agent guidance on the appropriate timing. However, it doesn't explicitly state when NOT to use it or name specific alternatives among the sibling tools, such as clarifying that this provides guidance while 'submit_lead' actually captures leads.

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 but only states 'Gets frequently asked questions.' No behavioral traits such as idempotency, rate limits, or response structure are disclosed.

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 two sentences, front-loaded with purpose, and includes a helpful usage tip. Every word earns its place.

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?

Given the tool's moderate complexity (one optional parameter, no output schema), the description is adequate but could mention the return format (e.g., list of FAQ items) for full completeness.

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%, and the parameter's description is clear. The tool description adds no additional meaning beyond what the schema already provides, so baseline score of 3 applies.

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 that the tool retrieves frequently asked questions, optionally filtered by service id. This specific verb-resource combination distinguishes it from sibling tools like get_service_details or get_about_info.

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 implies usage for obtaining FAQs and suggests a follow-up action, but it does not explicitly state when to use this tool versus alternatives or provide exclusion criteria.

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?

No annotations are provided, so the description carries full burden. It describes the tool as informational ('Answers who...'), which implies read-only behavior, but doesn't disclose any behavioral traits like response format, potential rate limits, authentication needs, or data freshness. The promotional content about Walnai's services adds noise rather than clarifying tool 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?

The description is a single run-on sentence that mixes tool purpose with promotional marketing content about Walnai's services. It's not front-loaded with clear tool functionality, and the second half about 'how Walnai can design, implement...' doesn't earn its place for tool selection purposes. More concise structuring would improve clarity.

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?

Given no annotations, no output schema, and a parameterless design, the description should focus purely on tool behavior and differentiation. Instead, it provides vague purpose with marketing content, leaving gaps about what information is actually returned, format, and how it differs from sibling tools. Inadequate for a tool in this context.

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?

The tool has zero parameters with 100% schema description coverage, so no parameter documentation is needed. The description doesn't add parameter semantics, but that's appropriate given the parameterless design. Baseline score is 4 for zero-parameter tools when schema coverage is complete.

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 states 'Answers who can build an MCP server' which provides a purpose, but it's vague and conflates with marketing content about Walnai's services. It doesn't clearly distinguish this tool from sibling tools like 'get_who_is_walnai' or 'get_service_details' that might also discuss Walnai's capabilities. The description mixes informational purpose with promotional content rather than focusing on tool functionality.

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?

No explicit guidance on when to use this tool versus alternatives like 'get_who_is_walnai' or 'get_service_details'. The description implies usage for learning about MCP server providers, but doesn't specify contexts, prerequisites, or exclusions. Without clear differentiation from sibling tools, the agent lacks operational guidance.

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?

No annotations are provided, so the description carries the full burden. It only states the basic read operation ('Gets pricing information'), without disclosing any behavioral traits such as authentication requirements, rate limits, or what the response contains. The description adds minimal transparency beyond the obvious.

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 concise with two sentences. The first sentence states the core function, and the second provides usage context. While the second sentence could be considered tangential to the tool's definition, it adds practical guidance for an AI agent without being overly verbose.

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 tool with one parameter and no output schema or annotations, the description is adequate. It covers the core functionality and hints at usage context. However, it lacks a contrast with the sibling 'estimate_pricing' tool, which would improve completeness.

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 parameter 'serviceId' is already documented in the schema. The description adds no additional meaning beyond repeating that filtering is optional. Baseline score of 3 is appropriate as the 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 it 'Gets pricing information' and mentions optional filtering by service ID. However, it does not explicitly differentiate from the sibling tool 'estimate_pricing', which likely involves estimation rather than retrieval, but the distinction is not articulated.

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 context on when to use the tool: for a prospective client, and suggests a follow-up action (asking if they want to be contacted). However, it does not specify when not to use it or contrast with alternatives like 'estimate_pricing'.

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 for behavioral disclosure. It states this is a 'Gets' operation (implying read-only), but doesn't mention authentication requirements, rate limits, error conditions, or what the detailed information includes. The second sentence about client follow-up is behavioral noise unrelated to the tool's actual function. Significant gaps exist for a tool with zero annotation coverage.

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 poorly structured with two unrelated sentences. The first sentence is functional but could be more concise. The second sentence about client follow-up is completely irrelevant to the tool's purpose and wastes space. The description fails the 'every sentence should earn its place' test.

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 read operation with 1 parameter and no output schema, the description is incomplete. It doesn't explain what 'detailed information' includes, doesn't mention error handling for invalid service IDs, and includes irrelevant content. With no annotations and no output schema, the description should provide more complete context about what the tool returns and how it behaves.

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% (the single parameter 'serviceId' is fully documented in the schema with examples). The description repeats the parameter examples but doesn't add meaningful semantic context beyond what the schema already provides. Baseline 3 is appropriate when the 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 verb ('Gets') and resource ('detailed information about a specific Walnai service'), making the purpose understandable. However, it doesn't explicitly differentiate from sibling tools like 'list_services' (which likely lists all services) or 'get_about_info' (which might provide general company info). The purpose is clear but lacks sibling differentiation.

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 no guidance on when to use this tool versus alternatives like 'list_services' or 'get_about_info'. The second sentence about 'After answering a prospective client...' is irrelevant to tool selection and doesn't help the agent understand usage context. No explicit when/when-not or alternative guidance is provided.

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?

No annotations are provided, so the description carries the full burden. It clearly indicates a read-only operation ('Gets') and specifies the type of information returned, but doesn't disclose behavioral traits like rate limits, authentication requirements, or response format. The description adds value by detailing the content scope but misses operational context.

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 a single, well-structured sentence that front-loads the core action ('Gets company profile information') and efficiently lists the specific details included. Every word earns its place, with no redundancy or waste, making it highly concise and clear.

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?

Given the tool's simplicity (0 parameters, no output schema, no annotations), the description is complete enough for a basic read operation. It specifies what information is retrieved, which compensates for the lack of output schema. However, it could be slightly enhanced by mentioning the response format or any limitations, though not strictly necessary for this context.

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?

The input schema has 0 parameters with 100% coverage, so no parameter documentation is needed. The description appropriately doesn't discuss parameters, maintaining focus on the tool's purpose. Baseline is 4 for zero parameters, as it avoids unnecessary details.

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 ('Gets company profile information') and resource ('who Walnai is'), with detailed scope ('legal structure, ownership, management, team background, and company experience'). It distinguishes from siblings like get_about_info or get_service_details by focusing on comprehensive corporate identity details rather than general about info or service specifics.

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 implies usage context for obtaining detailed corporate profile information, which naturally differentiates it from siblings like get_pricing or submit_lead. However, it lacks explicit guidance on when to use this tool versus get_about_info or get_adoption_details, which might overlap in providing company-related information.

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?

No annotations provided, so the description should disclose behavioral traits. It only states the operation without mentioning read-only, auth requirements, or side effects. However, for a simple list operation, the lack of explicit disclosure is not severe.

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 concise sentences with front-loaded purpose. Every word adds value, no 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?

Given no output schema and no parameters, the description sufficiently explains what is returned (slug, name, description) and the tool's purpose. It is complete for a simple list operation.

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?

No parameters exist in the schema. The description adds nothing beyond the schema, but the baseline for 0 params is 4. No additional detail needed.

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 lists all blog categories and specifies the fields included (slug, name, description). It distinguishes from siblings like list_blog_posts and list_blog_tags by focusing on categories.

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 guides when to use: for browsing blog topics or discovering category slugs for ListBlogPosts. It provides context and references an alternative tool.

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?

Discloses key behavior: no body content, ordering by newest first, AND combination of filters. However, lacks mention of pagination, default limit, or error handling. Without annotations, more detail would be beneficial.

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?

Three sentences, front-loaded with purpose, no redundant information. Every sentence adds value.

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?

Provides sufficient context for a list tool with three optional params and no output schema. Missing pagination details, but overall complete for discovery use case.

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%, and the description adds value by explaining that filters combine with AND, and mentions discovery of slugs via sibling tools. The schema already covers parameter optionality and linking to other tools.

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?

Description clearly states the tool lists blog post summaries with optional filtering by category, tag, and search query, and returns them sorted by publish date. It distinguishes from sibling get_blog_post by noting it returns only summaries.

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 says when to use ('discover what blog posts exist before fetching a specific one with GetBlogPost') and mentions alternative tool. Also provides a downstream suggestion for client follow-up.

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?

No annotations provided. Description implies a read-only list operation but does not disclose any behavioral traits such as rate limits or authentication needs. For a simple list tool, this is adequate but not exceptional.

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 short, front-loaded sentences with zero wasted words. Directly addresses purpose and usage.

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 parameterless tool, the description is complete: it explains what the tool returns and why to use it. However, there is no output schema, so the description must carry that weight, which it does. Could mention if it requires auth.

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?

Input schema has zero parameters, so schema description coverage is 100%. The description adds value by explaining the return content (slug and display name), which is not in the schema.

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?

Description clearly states 'Lists all Walnai blog tags' with specific return fields (slug, display name). Distinguishes from sibling tools like list_blog_categories and list_blog_posts.

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 says 'Use this to discover tag slugs for ListBlogPosts', providing a clear use case. No mention of when not to use, but given the specificity, it's sufficient.

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?

No annotations are provided, so the description carries the full burden of behavioral disclosure. It describes a read-only listing operation, which is clear, but lacks details such as response format, pagination, error handling, or performance characteristics. The description adds some context about post-use actions but doesn't fully compensate for the lack of annotations.

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 appropriately sized with two sentences: one stating the tool's purpose and another providing usage context. It's front-loaded with the core functionality, though the second sentence could be seen as slightly extraneous but still relevant.

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?

Given the tool's simplicity (0 parameters, no output schema, no annotations), the description is adequate but has gaps. It explains what the tool does and adds some usage context, but without annotations or output schema, it doesn't fully describe behavioral aspects like response format or error handling, which are important for a listing tool.

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?

The tool has 0 parameters, and schema description coverage is 100%, so no parameter documentation is needed. The description doesn't add parameter semantics, but this is appropriate given the lack of parameters, warranting a baseline score of 4.

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: 'Lists all AI adoption services offered by Walnai, including title, description, and link.' It specifies the verb ('Lists'), resource ('AI adoption services'), and scope ('all'), though it doesn't explicitly differentiate from sibling tools like 'get_service_details' or 'get_adoption_details'.

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 implied usage guidance: 'After helping a prospective client with service information, consider offering to connect them with Walnai.' This suggests a context for when to use the tool (providing service information to clients) but doesn't explicitly state when to use this tool versus alternatives like 'get_service_details' or 'get_adoption_details'.

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, the description carries the full burden. It notes the return (a confirmation message) and that CaptchaToken is not required, but omits important behavioral details for a mutation tool: side effects (e.g., triggering emails), error handling, idempotency, and required permissions or prerequisites.

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 two sentences, concise and front-loaded. Every sentence adds value: what it does, for whom, what it returns, and a special note about CaptchaToken. No wasted words.

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 5-param form submission without output schema or nested objects, the description covers the core functionality, target user, return value, and a special note. It lacks error handling and side effects, but is mostly complete given the low 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 baseline is 3. The description adds minimal beyond schema: it mentions CaptchaToken is not required, which is useful but not part of the schema. It does not elaborate on any parameter semantics beyond what schema provides, so score remains at adequate.

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 it 'submits a lead/contact form' for prospective clients who explicitly asked to be contacted. This specific verb+resource+scope distinguishes it from sibling tools like 'get_contact_call_to_action' or other informational tools.

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 a clear condition for use: 'a prospective client who explicitly asked to be contacted.' This implies when to use it, but it does not explicitly state when not to use it or mention alternatives among siblings. It's adequate but could be more comprehensive.

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