Dashform MCP Server

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

Annotations only indicate readOnlyHint=false, leaving the description to convey behavioral details. It adds value by stating the operation returns DNS instructions and requires owner/admin privileges, which goes beyond the structured annotations. It could disclose more about side effects, but the provided context is meaningful.

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, front-loaded sentence with no wasted words. It efficiently conveys the action, scope, permissions, and return 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?

For a simple tool, it covers core behavior, permissions, and return info, but omits parameter format and any follow-up steps like verification. The absence of an output schema means the description should ideally be more detailed about the DNS instructions or post-add behavior.

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 0%, so the description must compensate for parameter meaning. It does not explain the expected format of the 'domain' parameter or provide examples, leaving the agent to guess. This is a notable gap even with only one parameter.

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 specifies the action (add), the resource (custom domain), the scope (active org), and a key output (DNS instructions). It distinguishes from sibling tools like remove_custom_domain and list_custom_domains by stating the 'add' operation.

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 usage context by specifying 'active org' and an explicit access restriction ('Owner/admin only'). It does not name alternatives or when-not-to-use, but for a simple mutation tool, the intended use is evident from the verb and scope.

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?

Given the readOnlyHint annotation, the description adds useful behavior: 'single-shot' and 'the analytics agent may query the data to respond.' This clarifies that the tool performs internal queries but returns only the final answer, which is beyond what annotations state.

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 the main purpose front-loaded and parenthetical details about behavior. 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?

The description covers the tool's purpose, return value, and internal behavior. Since no output schema exists, noting that it returns the assistant's final answer is sufficient, though it could mention potential latency or cost.

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 description adds no parameter-level detail; the messages parameter is already described in the schema as 'Conversation so far; the last user message is answered.' With 50% schema coverage, the description doesn't compensate for formId, but the name and context make it self-evident.

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's function: asking a natural-language question about a form's replies and returning the final answer. This distinguishes it from raw data tools like list_replies or get_replies_insights by emphasizing the natural-language interface.

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 use for analytical queries but does not explicitly contrast it with alternatives like list_replies or get_replies_insights. No when-not-to-use guidance is provided, so the agent must infer from the phrase 'natural-language question'.

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?

The description discloses that the delete is permanent and requires a confirm flag to proceed, which adds valuable safety context beyond the annotations (destructiveHint=true). It also communicates the batch limit of 100 replies, enhancing transparency.

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, front-loaded sentence with no waste. It conveys all essential information efficiently.

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 destructive batch operation with no output schema, the description covers the action, the limit, and the confirmation requirement. It is sufficient for an agent to select and invoke the tool correctly without further elaboration.

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 low (33%), but the description adds meaning to key parameters: 'up to 100 replies' clarifies the ids array limit, and 'Pass confirm: true' explains the confirm flag's role. formId remains self-explanatory from 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 function: 'Permanently delete up to 100 replies of a form.' It uses a specific verb ('delete'), identifies the resource ('replies of a form'), and specifies a limit ('up to 100'), which distinguishes it from singular delete_reply and other delete 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 implies usage for batch deletion but does not explicitly state when to use this tool versus alternatives like delete_reply. It does provide a required action ('Pass confirm: true to proceed'), which is a usage prerequisite, but lacks comparative guidance or exclusions.

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?

The description discloses key side effects not fully captured by annotations: 'Creates a reply record visible in the dashboard and triggers connected integrations (CRM, email, webhooks).' This adds meaningful context about persistence and external effects. While annotations already indicate a non-read-only operation, the description enriches understanding without contradicting them.

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 and well-structured: a clear purpose sentence followed by two supporting sentences on behavior and compatibility. Every sentence adds value, and there is no redundancy or extraneous detail.

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 7 parameters, nested objects, and no output schema, the description provides essential context: how to use answers, what side effects occur, and the legacy option. It lacks details on output/return values or error cases, but given the presence of annotations and no output schema, the description covers the core usage adequately.

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 57% schema description coverage, the description partially compensates by explaining the 'answers' parameter ('keyed by question keys from get_form_questions') and the legacy 'lead' object. However, it does not add meaning for parameters like notes, metadata, fit_score, or service_name, which rely on schema descriptions. Some improvement is still needed for full semantic clarity.

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: 'Submit a lead's information to request an appointment.' It also specifies that it creates a reply record and triggers integrations, differentiating it from generic reply creation or other lead-related tools. The mention of using question keys from get_form_questions provides a clear connection to a sibling tool, further clarifying its unique role.

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 strong usage context by instructing to 'Provide answers keyed by question keys from get_form_questions,' implying a prerequisite call. It also notes the legacy lead object for backwards compatibility, helping users decide between parameters. However, it does not explicitly state when to prefer this tool over alternatives like create_reply or check_fit, leaving some room for ambiguity.

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?

Annotations only declare readOnlyHint=false and openWorldHint=false, so the description must disclose the mutation behavior. It does so by stating 'applies edits (persisted),' making the persistence explicit. It also mentions that it reads the form and returns a summary plus the updated form, adding behavioral value beyond the 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 two sentences, front-loaded with the main purpose, and every sentence carries useful information. There is no redundancy or fluff.

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?

With no output schema and sparse annotations, the description needs to cover return behavior and edge cases. It does mention the return (summary + updated form) but does not describe potential failure modes, limitations of the conversational editing, or how the tool handles ambiguous requests. It is adequate for a simple tool but incomplete for the complexity of natural language editing.

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 0%, so the description must compensate for the lack of parameter documentation. It references 'form id' and 'conversation' but does not explain the structure of the messages array (e.g., roles, text fields). The schema itself lacks descriptions, leaving the agent without sufficient parameter semantics.

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 'Conversationally edit a form' with a specific verb and resource. It also details the flow (read, apply edits, return summary + updated form), which distinguishes it from sibling tools like get_form, create_form, and update_form.

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 the use case (when you need to edit a form through a chat conversation) but does not explicitly state when to use this tool over alternatives like update_form, nor does it provide exclusions. The context is clear but lacks explicit alternative 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?

Annotations already declare readOnlyHint=true and destructiveHint=false. The description adds valuable behavioral details: the return payload (score, fit assessment, confidence, reasoning, next action) and legacy lead object support. This goes beyond what annotations alone provide, though it doesn't cover rate limits or error cases.

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 the primary action, and every sentence delivers distinct information (purpose, input/output, legacy compatibility). No redundancy or filler.

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?

The description covers the essential context: what to provide, what it returns, and legacy support. With no output schema, it adequately conveys return values. It doesn't explicitly state the prerequisite step of calling get_form_questions first, but the mention of question keys implies it, leaving only a minor workflow gap.

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?

All parameters have schema descriptions, so the baseline is 3. The tool description largely repeats the answers format ('keyed by question keys from get_form_questions') and legacy lead object, adding no new details like value constraints or examples beyond 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?

The description opens with a specific verb+resource ('Evaluate lead fit against this business') and clearly specifies the output (score, fit assessment, confidence, reasoning, next action). Referencing get_form_questions differentiates it from sibling tools like rescore_form_replies or override_verdict, making its purpose unambiguous.

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 clearly implies a workflow: fetch question keys via get_form_questions, then provide answers keyed by those keys. It also warns that the lead object is legacy. However, it does not explicitly name alternatives or state when not to use the tool, so it stops short of full 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?

The description adds the key behavioral requirement 'Pass confirm: true to proceed', which is not disclosed by the annotations themselves. This complements the destructiveHint and idempotentHint annotations, providing practical invocation context beyond the structured metadata.

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 consists of two short sentences, front-loading the core action and then providing the critical confirmation requirement. Every word is purposeful with no redundancy or filler.

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 destructive tool with 2 parameters and no output schema, the description covers the essential behavior (clearing all messages), the input identifier, and the confirmation flag. The annotations already flag destructiveness and idempotency, so the description need not repeat those. It is sufficient for an agent to invoke the tool correctly.

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 documents only 'confirm' with a description, leaving 'referenceId' without explanation. The description clarifies that 'referenceId' refers to the chat's identifier, partially compensating for the schema gap. It also reinforces the confirm parameter's purpose.

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 action ('Clear all messages'), the resource ('in a chat'), and the required identifier ('by its reference ID'). This distinguishes it from sibling tools like delete_chat or load_messages, which either target the chat itself or retrieve messages.

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 the tool is used when you need to clear all messages in a specific chat, and it mentions the need for a reference ID. However, it does not explicitly contrast with alternatives such as delete_reply or batch_delete_replies, nor does it state when not to use this 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?

Annotations already indicate mutation (readOnlyHint=false). The description adds valuable context beyond annotations: 'Start and end screens are added automatically unless you supply your own' and the need to call publish_form. This clarifies non-obvious 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?

Three sentences, each adding distinct value: purpose, type differences, automatic behavior, and follow-up action. Front-loaded and free of fluff.

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?

Despite the complex nested schema, the description covers the essential decisions (type, auto-generated screens, publishing). No output schema exists, but for a creation tool, the description gives enough context to select and invoke correctly while the schema details the rest.

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 top-level parameter `form` lacks a description in the schema (0% coverage), so the description compensates by summarizing its contents: 'name, steps, theme and settings together.' It also explains the 'structured' vs 'dynamic' types, reinforcing the schema enum semantics.

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 'Create a complete form in one call' with specifics on what's included (name, steps, theme, settings). It distinguishes the tool from update_form by emphasizing creation and from publish_form by instructing to call it afterwards.

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?

Provides practical guidance: 'Call publish_form afterwards to take it live.' Implies this is for initial creation rather than updates, but doesn't explicitly mention when to use update_form instead. The tip about automatic start/end screens also helps usage.

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?

Annotations already indicate readOnlyHint=false, so the mutation nature is clear. The description adds that it creates a new integration and maps answers, but does not disclose permissions, side effects, or behavior with existing integrations. No contradiction with 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 a single, front-loaded sentence with no filler. Every word contributes to understanding the tool's purpose and key behavior.

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?

The tool has 4 required parameters, no output schema, and sparse annotations. The description gives a high-level overview but does not mention return values, error conditions, or prerequisite knowledge (e.g., connectionId). It is adequate for a simple create operation but lacks depth for full agent decision-making.

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 0%, so the description must compensate. It clarifies fieldMapping by mentioning mapping form answers to columns, and implies connectionId connects to the listed spreadsheet services. However, defaultColumns and parameter nuances are not explicitly explained, leaving some gaps.

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 ('Create'), resource ('integration'), and scope ('on a form, mapping form answers to columns'). It explicitly names spreadsheet-style platforms (Google Sheets/Airtable/Notion), which distinguishes it from sibling tools like create_webhook_connection or create_integration_from_config.

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 spreadsheet-style integrations but does not explicitly state when to choose this tool over alternatives. No exclusions or alternative tool references are provided, leaving the agent to infer context from the word 'spreadsheet-style'.

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?

The annotations indicate readOnlyHint=false, which aligns with 'Create' (no contradiction). However, the description adds no extra behavioral context such as side effects, whether it validates the config, or what happens to existing integrations. It does not mention potential failures or required preconditions.

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 concise sentence, well front-loaded for quick scanning. However, its brevity sacrifices important details and includes an incomplete list of integration types, which reduces its effectiveness despite its compactness.

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 complex actionConfig schema (with 9 distinct integration kinds) and no output schema, this description is too minimal. It omits several supported integration types and provides no guidance on navigating the config variants, making it inadequate for an agent to understand full usage 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?

Schema description coverage is 0%, so the description must compensate by explaining parameter semantics. It fails to do so; it only references 'full action config' without explaining the structure of actionConfig or the role of formId/connectionId. For a complex multi-variant schema, this is insufficient.

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 ('Create') and resource ('integration on a form'), but the phrase 'message-style integration' inaccurately limits the scope since the actionConfig schema includes Google Sheets, Airtable, Notion, and email integrations. It also does not explicitly differentiate from sibling tool create_integration, though 'from a full action config' hints at a distinguishing factor.

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?

Provides no guidance on when to use this tool versus alternatives like create_integration or toggle_integration. No mention of prerequisites (e.g., needing an existing connection) or scenarios where this is the preferred choice.

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?

Annotations only mark the tool as readOnlyHint=false. The description adds meaningful behavioral details beyond that: the return value (a checkout URL) and the email verification requirement. This is more than minimal, though it doesn't detail failure modes or side effects.

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 the verb and purpose. It wastes no words and is easy to parse, while still covering the core action, output, and a key requirement.

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 checkout tool with no output schema, the description covers the essential context: what it does, what it returns, and a precondition. However, it omits any explanation of the parameters or how different productIds map to credit amounts, which leaves some ambiguity.

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 0%, so the description must compensate for explaining parameters. It does not mention productId or successUrl at all, leaving the agent to infer their roles solely from the schema's enum and format. This is a significant gap.

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 action: 'Create a checkout session to purchase quiz credits.' It also specifies the output ('Returns a checkout URL'), making the tool's purpose unambiguous and distinct from siblings like get_quiz_credits_status.

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 context for use (purchasing quiz credits) and a prerequisite ('Requires a verified email'). However, it does not mention alternative tools or explicitly state when not to use it, so it falls short of a 5.

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?

Annotations already indicate a write operation (readOnlyHint=false). The description adds the behavioral constraint that it operates on the latest published version, which is useful context. However, it does not disclose side effects such as triggering integrations, webhooks, or what happens if no published version exists.

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 concise sentences that clearly state the core action and optional inputs, with no redundant or filler content. It is front-loaded with the primary purpose.

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 complexity—six parameters, a nested data object, enum types, and no output schema—the description is too terse. It omits important context such as what partial vs completed status means, how respondent info is validated, and what the tool returns or does on success/failure.

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 only 33%, with only data and formId described. The tool description generically mentions 'respondent info and answers' but does not explain status enums, respondentName/email/emotion fields, or the difference between partial and completed statuses. This does not compensate for the missing schema descriptions.

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 ('Create') and a clear resource ('reply on the form's latest published version'), making the tool's function unambiguous. It naturally distinguishes itself from sibling tools like delete_reply, list_replies, or get_reply.

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 explicitly state when to use this tool compared to alternatives, nor does it mention exclusions or prerequisites beyond the implied need for a published form. It simply states what the tool does without guiding tool selection in a broader workflow.

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?

The description adds meaningful context beyond the sparse annotations (readOnlyHint: false) by clarifying that the tool does not use OAuth and that other integrations require a separate OAuth flow. This helps set expectations about the connection method, though it does not detail any validation or post-create 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 two sentences, front-loaded with the core purpose, and contains no fluff. Every sentence provides essential information about scope 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?

The description is sufficient for basic tool selection and provides clear usage boundaries, but it is incomplete for full invocation. It does not explain the optional parameters, and without an output schema, it does not indicate what the tool returns after creation. The tool is relatively simple, so the gap is moderate.

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 0%, so the description must compensate. It clarifies that provider can be 'webhook' or 'discord' and that OAuth is not used, but it does not explain the purpose of 'accountLabel' or 'signingSecret', leaving those parameters ambiguous. The description adds minimal value beyond the schema's enum and format constraints.

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 creates a webhook or Discord connection, with a specific verb and resource. It distinguishes from OAuth-based connections by explicitly noting 'no OAuth' and referencing the dashboard flow for other providers like Slack, HubSpot, or Mailchimp.

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 by stating that Slack/HubSpot/Mailchimp/etc. should be connected via the dashboard's OAuth flow, implying this tool is only for webhook or Discord connections. This effectively tells the agent when to use this tool vs 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?

Annotations already declare destructiveHint=true and idempotentHint=true, so the safety profile is covered. The description adds the crucial confirm:true requirement, telling the agent that deletion requires explicit confirmation, which is a behavioral safeguard. No contradictions with 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?

Two short sentences front-load the purpose and the necessary confirmation step. Every word earns its place; no redundancy or filler.

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 delete operation, the description plus annotations cover the essential context: what gets deleted (blob by URL), the required confirmation, and the destructive nature. No output schema is needed for a void operation, and the confirm flag is properly highlighted. Could include side effects or irreversibility, but that's already inferred from destructiveHint.

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 only 50% (confirm has a description, url does not). The description adds meaning to url by specifying 'by its URL' and to confirm by saying 'Pass confirm: true to proceed.' This compensates for the sparse schema, making both parameters self-explanatory.

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 'Delete' and resource 'a blob' identified by URL. It clearly distinguishes from sibling delete tools (delete_chat, delete_form, etc.) by specifying the target type. Also mentions confirm requirement, adding clarity.

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 when to use—when you need to delete a blob by URL. However, it doesn't explicitly contrast with alternative delete tools or provide exclusions, leaving the decision to the agent based on resource type. Since the resource type is unique, the context is inherent but not explicitly stated.

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?

Annotations already declare destructiveHint=true and readOnlyHint=false, so the 'permanently delete' wording is redundant. However, the description adds crucial safety context beyond annotations: the requirement to pass confirm: true to proceed. It does not disclose other traits like irreversibility or what happens if the chat doesn't exist, but the confirmation mechanism is valuable.

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 short sentences, front-loaded with the action and resource ('Permanently delete a chat by ID'), followed by essential confirmation guidance. Every word earns its place with no fluff.

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 two-parameter delete tool with strong annotations and a clear confirmation mechanism, the description covers the essential operational detail. It lacks mention of return behavior or edge cases (e.g., deleting a non-existent chat), but given the low complexity and annotation support, it is reasonably 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?

The schema provides a description for confirm ('Must be true to delete') but not for id. The tool description reinforces the meaning of confirm ('Pass confirm: true to proceed') and clarifies that id is the chat identifier, but adds little beyond what the schema already states. With 50% schema coverage, the description partially compensates but does not fully enrich parameter semantics.

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 a specific verb ('delete'), a resource ('chat'), and the required identifier ('by ID'). It also distinguishes from sibling delete tools like delete_reply and delete_form by naming the exact resource type.

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 (deleting a chat) but does not explicitly state when to use this tool versus alternatives like clear_messages or delete_reply. No 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?

Annotations already provide destructiveHint=true and readOnlyHint=false. The description adds valuable context: the deletion is permanent, requires confirm:true, and cascades to integrations. It does not contradict the annotations and elaborates on destructive 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 short sentences, front-loaded with the core action and the critical confirmation requirement. Every word earns its place; no redundancy or fluff.

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?

The description covers permanence, confirmation, and cascading deletion, which is strong for a destructive tool. However, it omits mention of the revoke_connection alternative and behavior for non-existent connections, leaving some ambiguity for an 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?

Schema has 50% description coverage, with confirm's purpose already documented. The description reinforces the confirm requirement but adds no new meaning for id, which remains undocumented in the schema. It provides marginal value beyond 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?

The description clearly states it permanently deletes a connection and its integrations, using a specific verb and resource. It does not explicitly name alternative tools like revoke_connection, but the word 'permanently' hints at a distinction, preventing a 5.

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 is given on when to use this tool versus alternatives, such as revoke_connection or delete_integration. The description only explains the action, not the context or conditions for choosing it.

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?

Annotations already set destructiveHint=true and idempotentHint=true, but the description adds meaningful specifics: the permanent nature, the deletion of all versions and replies, and the requirement to pass confirm:true. This goes beyond the 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?

A single well-structured sentence delivers all essential information: action, scope, and the confirm prerequisite. 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 delete tool, the description is complete. It covers the destructive scope, the permanent nature, and the confirm gate. No output schema is needed for a delete operation, and the sibling context does not introduce ambiguity.

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 already documents both parameters with full coverage (100%). The description redundantly emphasizes 'Pass confirm: true to proceed' but does not add new meaning beyond what the schema provides. 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 clearly states the action ('Permanently delete'), the resource ('a form'), and the full scope ('all its versions and replies'). This distinguishes it from sibling tools like delete_reply and batch_delete_replies.

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 when to use this tool (to delete an entire form and its associated data) and mentions the confirm gate, but it does not explicitly contrast with alternatives like delete_reply or list_forms. The usage context is clear but not fully explicit about when not to use it.

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?

Beyond the annotations (destructiveHint true), the description adds the permanent nature of the deletion and the confirmation requirement via confirm: true, which is not captured in the 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 a single, well-structured sentence that immediately conveys the action and the required confirmation flag.

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 and the annotations covering destructive/idempotent behavior, the description adequately covers the main usage. It does not explain return values, but no output schema exists and the behavior is straightforward.

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 description references confirm but merely restates the schema's existing description. The id parameter lacks any description in the schema, and the description does not compensate by explaining how to identify the integration.

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 the specific verb 'delete' with the resource 'integration from a form', clearly distinguishing it from sibling tools like toggle_integration and list_integrations.

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 indicates the primary usage—permanent deletion—and instructs to pass confirm: true, but it does not explicitly mention alternatives or when not to use this 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?

Description explicitly discloses permanence and requires confirm:true, adding a safety guardrail beyond the annotations' destructiveHint and idempotentHint. No contradiction with 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?

Two short sentences, front-loaded with the core action and immediately followed by the critical confirmation requirement. 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?

For a simple delete operation with two well-documented parameters and appropriate annotations, the description provides everything needed to invoke correctly. No output schema needed.

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 covers both parameters with descriptions, and the description's confirm instruction largely repeats schema's 'Must be true to delete'. No additional semantic value beyond 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 states 'Permanently delete a single reply' with a specific verb and resource, clearly distinguishing it from batch operations like batch_delete_replies.

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 phrase 'a single reply' implies usage for one deletion at a time, but no explicit comparison or alternative is mentioned. Context is present but not fully developed.

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?

Annotations already declare destructiveHint=true and idempotentHint=true. The description adds valuable context beyond annotations: 'Permanently' emphasizes irreversibility, and 'Pass confirm: true to proceed' discloses the safety gate behavior. This is exactly the kind of additional context the rubric rewards.

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 sentences, front-loaded with the action and required confirmation. Every word earns its place; no redundancy or filler.

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 destructive tool with two parameters, no output schema, and annotations covering destructive/idempotent behavior, the description is adequately complete. It specifies the deletion, the required confirmation, and the permanence. Could mention a prerequisite like 'hook must exist' but that is minor for this 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?

Schema description coverage is 50% (only confirm has a schema description). The description repeats the confirm requirement ('Pass confirm: true to proceed') which is already in the schema, and doesn't add new meaning for hookId. Baseline of 3 is appropriate since the schema does most of the heavy lifting for the documented parameter.

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 the specific verb 'delete' and clearly identifies the resource ('Zapier webhook subscription'). It distinguishes this from sibling tools like toggle_zapier_hook (toggle) and list_zapier_hooks (list).

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?

Provides clear context: this is for permanent deletion and requires confirm: true to proceed. It implies when to use (when you want to permanently remove a subscription) but does not explicitly mention alternatives like toggle_zapier_hook for temporary disabling. Lacks exclusions, so not a 5.

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?

Annotations already indicate readOnlyHint=true, so the safe-read nature is known. The description adds value by specifying the 'Owner only' access requirement and 'active org's' scope, going beyond the annotations' basic safety hint.

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 short sentences, front-loaded with the primary action and scope. Every word adds value, with no redundancy or filler.

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?

The tool is a simple getter with no output schema. The description covers purpose, scope, and access, but does not elaborate on what the status response contains. This is a minor gap given the tool's trivial nature, but the description is sufficient for basic understanding.

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, and the schema has 100% coverage (empty properties). The description correctly adds no parameter details since none exist, aligning with the baseline for no-parameter 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?

The description clearly states the tool retrieves the active org's BYOK AI provider status, with a specific verb and resource. It distinguishes itself from sibling tools like save_ai_provider_key and remove_ai_provider_key by focusing on 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 notes 'Owner only,' providing a clear access prerequisite. While it doesn't explicitly state when not to use it or name alternatives, the context of sibling read/write tools makes the usage context clear.

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?

Annotations already indicate readOnlyHint=true and destructiveHint=false, but the description adds useful context by explaining the return value: a booking link if configured, or a message about scheduling. This goes beyond the annotations to clarify what the agent can expect, though it doesn't mention any side effects or error scenarios.

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 and well-structured: two sentences that immediately state the purpose and then the expected return values. No unnecessary information, 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 simple tool with one parameter, full schema coverage, and clear annotations, the description provides enough context. It explains the output type (link or message), which is crucial given the absence of an output schema. The description is complete for an agent to invoke this tool correctly.

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 already provides a complete description for funnel_id ('The funnel public ID or internal ID'), covering 100% of parameters. The tool description adds no additional parameter meaning, so the baseline score of 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 clearly states the tool's purpose: 'Get booking availability for this business.' It specifies the verb (get) and resource (booking availability) and distinguishes it from sibling tools like book_appointment by focusing on availability rather than the booking action.

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 that this tool is for checking availability, suggesting an alternative for booking (book_appointment), but it does not explicitly state when to use this tool versus alternatives. The context is understandable but not definitively differentiated.

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?

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds value by listing the returned fields and clarifying the target entity, but does not go into error cases or pagination.

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, action-first, with no wasted words. The first sentence states what the tool does and the second gives a concrete use case.

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-only query with one parameter and no output schema, the description fully covers purpose, usage context, and the nature of the return data. It is self-contained and unambiguous.

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% for the single funnel_id parameter, which is already well described as 'The funnel public ID or internal ID'. The tool description does not add parameter-specific detail, so 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?

Clearly states it retrieves business information for a Dashform funnel and enumerates the specific fields returned (description, industry, location, services, booking link). Distinguishes from sibling get_* tools by focusing on business entity data rather than forms, chats, or connections.

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?

Provides explicit usage context: 'Use this to understand what a business offers before checking lead fit.' This tells the agent when to call it, though it does not name alternatives or exclusion cases.

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?

The readOnlyHint annotation already declares this is a safe read operation, so the description only needs to add context. It clarifies that a chat is a 'form-editor conversation' and that lookup is by reference ID, but it does not describe return behavior, error cases, or other side effects. This is adequate for a simple getter.

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 concise sentence that front-loads the operation and key parameter. Every word earns its place with no filler 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 get tool with one parameter and a readOnly annotation, the description is complete enough to convey the resource and lookup key. However, since there is no output schema, it does not specify the return format, but that is often implicit for retrieval tools.

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 0%, so the description must explain the referenceId parameter. The phrase 'by its reference ID' essentially restates the parameter name without adding format, source, or constraints. It does not compensate for the lack of schema-level documentation.

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 'Get a chat (e.g. a form-editor conversation) by its reference ID.' This clearly identifies the verb (get), the resource (chat), and the lookup method (reference ID). The example 'form-editor conversation' helps disambiguate the resource type from sibling tools like get_form or get_reply.

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 is provided about when to use this tool versus alternatives. The description simply states the operation with no mention of prerequisites, exclusions, or alternative tools, leaving the agent to 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?

The annotation readOnlyHint=true already discloses the safe read-only nature. The description adds minimal behavioral context beyond the ID lookup, not covering error handling, return shape, or permission requirements. No contradiction exists.

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, front-loaded sentence with no filler. Every word earns its place, perfectly concise.

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-only lookup with one required parameter and no output schema, the description is nearly complete. It doesn't explain the return value, but the operation is self-evident. Annotations cover safety. Minor ambiguity remains about what 'connection' refers to, but it is acceptable given the 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?

Schema description coverage is 0%, so the description must compensate. It does clarify that 'id' refers to the connection ID, adding meaning beyond the schema's type/required fields. However, it does not explain ID format or where it comes from, which is a minor gap for a single-parameter 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 'Get a single connection by ID' clearly specifies the action (get), resource (connection), and scope (single by ID). It distinguishes from siblings like list_connections and other get_* tools by indicating a targeted 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 implies when to use the tool (when you have a specific connection ID), but does not explicitly state when not to use it or provide alternatives. Sibling tools like list_connections suggest broader retrieval, but no direct guidance is given.

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 readOnlyHint=true and openWorldHint=false already provided, the description adds value by disclosing the output shape matches update_form and that unset attributes are omitted. This is meaningful behavioral context beyond the annotations, though it doesn't cover all possible edge cases (e.g., error 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 two sentences, front-loaded with the core action and scope, and every clause adds useful information (authoring vocabulary, update_form compatibility, omission behavior). 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?

The tool is simple (one parameter, no output schema), and the description adequately covers the return shape and its relation to update_form. It could be slightly more explicit about the response format or error cases, but for its complexity and the annotations provided, it is reasonably 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% (the id parameter is described as 'The form ID'), so the baseline is 3. The description does not add additional parameter-level detail, but none is critically needed given the simple single-parameter 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 a specific verb ('Get') and resource ('form by ID') with a clear scope ('authoring vocabulary'), distinguishing it from siblings like get_form_questions, get_form_version, and get_published_form_version. It also connects to update_form, reinforcing its role in the editing workflow.

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 when to use this tool: when you need the form in an editable authoring shape compatible with update_form. It provides clear context but does not explicitly state exclusions or alternatives (e.g., when to prefer get_form_version or list_forms), so it falls just short of full 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?

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is known. The description adds value by specifying what the tool returns (keys, types, descriptions, options), which is behavioral context beyond the annotations. It stops short of disclosing potential edge cases like empty results or error handling, but this is minor for a simple read tool.

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, each earning its place: the first states purpose and return content, the second gives contextual usage. No redundant words or filler.

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 read-only tool with no output schema, the description fully covers what the tool does, what it returns, and when to use it. There are no critical gaps 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%, and the parameter 'funnel_id' is described as 'The funnel public ID or internal ID'. The description's reference to 'this funnel' adds no new parameter-level meaning, so it does not exceed the schema's 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 uses a specific verb 'Get' and clearly identifies the resource ('list of questions for this funnel'), distinguishing it from sibling tools like get_form and list_forms. It also enumerates the return contents (question keys, types, descriptions, options), making the purpose unmistakable.

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: 'Call this BEFORE check_fit or book_appointment'. This provides clear direction on the workflow context and differentiates it from related tools, offering an explicit alternative 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?

Annotations already declare readOnlyHint=true, so the safety profile is known. The description adds the specific state fields returned but does not disclose additional behavioral traits like response format, pagination, or edge cases. This is modest value beyond annotations, similar to the get_calls calibration example.

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, front-loaded with the verb and resource, followed by a concise colon-separated list. Every word earns its place with no filler or repetition.

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?

This is a simple 1-parameter read-only tool with no output schema, and the description adequately specifies the return contents (three pieces of state). It could be slightly more explicit about the response structure or potential null values, but it is sufficiently complete for the tool's simplicity.

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 0%, so the description must compensate. It indirectly clarifies that 'formId' refers to a form via 'a form's,' but it does not provide explicit format, constraints, or usage details beyond the schema's type and required flags. This is only marginal added meaning.

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 ('Get') and resource ('form's lead-scoring state'), and it enumerates exactly what is returned (pending hot-lead count, criteria active status, last criteria update). This clearly distinguishes it from siblings like get_form or get_form_version.

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 about what the tool returns, allowing an agent to infer when to use it (e.g., when needing lead-scoring state for a specific form). However, it does not explicitly name alternatives or mention when not to use it, so it stops short of a 5.

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?

The description does not contradict annotations (readOnlyHint=true). However, it adds no behavioral context beyond what annotations already provide, such as side effects, permissions, or limitations. The tool is a simple read, so the annotation suffices, but the description adds no extra credit.

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 one clear sentence, front-loaded with the verb and resource. Zero wasted words, and the single parameter is implied directly in the 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 simple one-parameter read operation, the description is minimally adequate. It does not clarify what the return value contains or how it differs from get_published_form_version, but given the tool's simplicity and annotations, it meets the minimum threshold.

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% since the 'id' parameter is fully described with 'The form version ID'. The tool description repeats this information ('by its version ID') without adding meaningful new semantics, so 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 clearly states the verb 'Get', the resource 'specific form version', and the key parameter 'version ID'. It distinguishes from sibling tools like get_form (gets form) and get_published_form_version (gets published version) by specifying a particular version.

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 such as get_published_form_version or get_form. It does not mention exclusions or provide context for selection.

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?

The description adds no behavioral context beyond the annotations. The readOnlyHint=true already signals a safe read operation, and the description merely restates the operation without disclosing return format, error behavior, or any other caveats.

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?

One short, front-loaded sentence ('Get a single integration by ID.') with zero wasted words. It is perfectly concise and immediately communicates the action.

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 get-by-ID tool with good annotations (readOnlyHint=true), the description is adequate. It doesn't explain return values or errors, but there is no output schema and the standard semantics are implied. It is complete enough for a low-complexity 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?

Schema description coverage is 0%, so the description must compensate. It does by stating 'by ID', which clarifies that the required 'id' parameter is the identifier of the integration. This is essential and adds meaning the schema lacks.

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 function with a specific verb ('Get'), a resource ('integration'), and a scope ('by ID'), distinguishing it from list_integrations (which returns multiple) and create/delete/toggle variants. This makes its purpose unmistakable.

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 conveys when to use the tool: to retrieve a single integration when you have its ID. It does not explicitly name alternatives or exclusions, but the word 'single' implies it is not for listing or modifying, providing clear context.

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?

Annotations already declare readOnlyHint=true and openWorldHint=false, so the safety profile is clear. The description adds value by specifying the exact data returned (logo, favicon, brand color) and scoping to the 'active' organization, which is useful context beyond the 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 a single, front-loaded sentence that immediately states the action and resource. It contains no fluff or redundant information, and 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?

For a simple getter with no parameters, no output schema, and readOnlyHint annotations, the description sufficiently covers the core purpose and return data. It does not specify the exact response structure or edge cases, but the tool's simplicity and the provided details make it adequately 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?

The tool has zero parameters, so the baseline is 4. The description does not need to explain parameter semantics, and none are provided in the schema. No additional parameter information is required.

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 the specific verb 'Get' and clearly identifies the resource ('active organization's white-label branding') with concrete examples (logo, favicon, brand color). This distinguishes it from sibling tools like update_org_branding and other get_* tools, making the purpose unambiguous.

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: call this when you need branding of the active organization. However, it does not explicitly state when to use it versus alternatives (e.g., get_business_info) or any exclusions. For a simple getter, the implied context is sufficient, but there is no direct 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?

Annotations already provide readOnlyHint=true and openWorldHint=false, which cover the safety profile. The description adds meaningful context by specifying the exact data returned (sender name, reply-to) and the scope (active org), going beyond the annotations without contradicting them.

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?

Single sentence, front-loaded with the verb, and every word adds value. No redundancy or filler.

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 getter with no parameters and no output schema, the description adequately covers the tool's purpose, scope, and key return fields. It is complete for an agent to correctly select and invoke the 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?

There are zero parameters, so the description doesn't need to explain them. The mention of 'active org' clarifies that the tool relies on the commonly understood active organization context, which is sufficient given the parameter count.

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 'Get', the specific resource ('active org's white-label email config'), and the key fields (sender name, reply-to). This distinguishes it from sibling tools like get_org_branding and update_org_email_config.

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 on what the tool retrieves (active org's email config), making it obvious when to use it. It lacks explicit exclusions or named alternatives, but the active-org scoping and resource specificity strongly imply its intended use case.

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?

Annotations already declare readOnlyHint=true, so the description does not need to restate safety. The description adds context that this returns the live published snapshot, but does not disclose other behavioral traits such as response structure, pagination, or error conditions. This is adequate but not rich.

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 immediately clarifies what the returned version represents. It contains zero wasted words and uses a parenthetical to add precision.

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-only tool with one parameter, good annotations, and a clear name, the description is sufficient. It could be more complete by describing the return payload shape, but no output schema exists and the tool name/parenthetical make the result predictable.

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 already documents formId with a description at 100% coverage. The tool description adds no additional parameter-level detail, so it meets the baseline of 3 for schema-covered parameters.

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 the specific verb 'Get' and clearly identifies the resource as 'the latest published version of a form', and the parenthetical 'live snapshot respondents see' distinguishes it from sibling tools like get_form_version and get_form.

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: it clarifies this tool returns the live published snapshot, which suggests when it should be used. However, it does not explicitly state when not to use it or mention alternatives such as get_form_version or get_form.

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 readOnlyHint annotation already present, the description adds the 'acting user' scope, which is useful context. It does not add further behavioral details such as return format or error conditions, so it only modestly exceeds what annotations already provide.

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?

A single, tight sentence that front-loads the verb and resource. Every word contributes to the meaning, with no wasted content.

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-only tool with no parameters and good annotations, the description adequately states the core purpose. It does not define 'status' in detail, but given the simplicity and lack of output schema, it is sufficiently complete for agent selection and invocation.

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, and the schema covers 100% of the (empty) properties. The baseline for no parameters is 4, and the description's mention of 'acting user' adds implicit context without needing to document parameter syntax.

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 function with a specific verb 'get' and resource 'acting user's quiz-credits balance and status'. It distinguishes itself from siblings by focusing on quiz credits status, unlike create_quiz_credits_checkout or other getters.

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 usage is implied: one would use this tool when needing the acting user's quiz-credits balance. However, there is no explicit when-to-use guidance or mention of alternatives/exclusions, which keeps it at the 'implied usage' level.

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?

Annotations indicate readOnlyHint=true, so the read-only nature is already known. The description adds useful behavioral context by specifying the kinds of insights (completion, drop-off, answer distributions) and that they are time-bounded. However, it does not describe return structure, pagination, or potential performance implications.

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, concise sentence that front-loads the main purpose. It includes the key qualifiers (form, time range, types of insights) without any waste. Every word 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?

Given no output schema and only two parameters, the description provides a high-level overview but omits details about the response format (e.g., whether values are counts, percentages, or time-series). It also does not state whether any authorization or specific form ownership is required. The tool is simple enough that this is a minor gap, but the absence of return-value info lowers the score.

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 0%, so the description must compensate. It mentions 'a form's replies' and 'time range,' which map to formId and timeRange, respectively. However, it does not clarify the meaning of the enum values (7d, 30d, 90d, all) or the exact role of formId, leaving some ambiguity that the schema alone cannot resolve.

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: 'Get aggregate insights for a form's replies over a time range.' It identifies the specific resource (form replies) and the type of output (completion, drop-off, answer distributions). This distinguishes it from sibling tools like list_replies and get_reply, which return raw reply data.

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 when to use the tool: when you need aggregate statistics rather than individual replies. It does not explicitly mention alternatives or exclusions, but the phrase 'aggregate insights' signals a clear use case. A more explicit reference to alternatives would earn a 5.

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?

Annotations already declare readOnlyHint=true, so the safe read nature is known. The description adds useful behavioral context by noting the response includes answers and scoring, which helps the agent understand the return payload. No contradictions or missing safety details beyond what annotations provide.

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, front-loaded sentence: 'Get a single reply by ID, including answers and scoring.' Every word earns its place, with no redundancy or filler.

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 get-by-id tool with one parameter, no output schema, and read-only annotations, the description is sufficiently complete. It tells the agent exactly what the tool does and what the response will contain, leaving no meaningful gaps.

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 full (100%) description coverage for the single 'id' parameter ('The reply ID'). The description's 'by ID' phrase adds no new semantic meaning beyond what the schema already provides, so the baseline score of 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 clearly states the verb (get), the resource (a single reply), and the identifier (by ID), while also specifying that answers and scoring are included. This distinguishes it well from sibling tools like list_replies (which fetches multiple) and create_reply/delete_reply.

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 the use case: retrieving a specific reply by its ID when its answers and scoring are needed. It does not explicitly name alternatives or exclusions, but the 'by ID' phrasing combined with sibling tool names (list_replies, get_replies_insights) gives clear contextual 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?

Annotations already declare readOnlyHint=true and openWorldHint=true, so the safety profile is covered. The description adds the funnel-scoping and category filter behavior but doesn't disclose pagination or ordering beyond what annotations provide.

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 sentences, front-loaded with the action, no wasted words. The optional category filter is clearly stated.

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 list tool with one required parameter and an optional filter, the description is adequate. It could mention return format or pagination, but given no output schema and low complexity, it's sufficiently 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 covers 100% of parameters with descriptions. The description's 'optionally filter by category' echoes the schema without adding new meaning, so the baseline of 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 clearly states it retrieves a list of services or products for a specific funnel, with optional category filtering. The verb 'Get' and resource scope distinguish it from mutation tools, though it doesn't explicitly differentiate from the sibling tool search_services.

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?

Implied usage is when you need a business's services for a given funnel, optionally filtered by category. No explicit when-not or alternatives are mentioned, but the funnel-centric scope provides some context.

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?

Annotations already declare readOnlyHint=true, and the description adds value by specifying exactly what data is returned (ID, email, name, active organization) and that identity comes from the OAuth token. This goes beyond the annotations by describing the data source and contained fields, without contradicting the read-only hint.

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, each earning its place: the first states the resource and outputs, the second explains the identity source and parameter absence. It is front-loaded and free of fluff.

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, read-only tool with no output schema, the description is complete. It lists the return fields (ID, email, name, active organization) and the authentication mechanism, leaving no critical gaps for an agent to use it correctly.

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 no parameters, and the schema coverage is trivially 100%. The description explicitly states 'no parameters needed', which confirms the zero-parameter expectation and adds a small but useful semantic. Baseline for zero params is 4, and this is appropriately met.

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 ('Get') and resource ('the authenticated user's ID, email, name, and the active organization'). It distinguishes itself from sibling tools by emphasizing the authenticated user context and active organization, which is unique among the many get_* 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 clear context on when to use the tool: when you need the authenticated user's identity or the active organization. It implies the OAuth token is required and that no parameters are needed. It does not explicitly mention alternatives or exclusions, but the context is clear enough for correct selection.

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?

Annotations already declare readOnlyHint=true, indicating a safe read operation. The description adds that it extracts from a URL and does not persist (via the note to use update_form), which aligns with the annotation. It does not disclose additional behaviors like rate limits or error handling, but given annotation coverage, a 3 is appropriate.

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 action and includes essential workflow guidance. Every word earns its place, with 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?

The tool is simple (one parameter, no output schema) and the description covers its core purpose, return behavior, and relationship to update_form. It does not detail the extracted profile structure, but given the simplicity and annotations, the description is sufficiently complete for effective invocation.

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 no property descriptions (0% coverage), but the description explicitly tells that the tool extracts 'from a website URL', giving meaning to the sole `url` parameter beyond its format. This compensates for the schema gap, though it lacks examples or edge-case 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 uses a specific verb ('Extract') and resource ('business/agent profile from a website URL'), and further clarifies the purpose ('for marketplace discovery'). It also differentiates from the sibling tool update_form by stating that this tool returns the extracted profile and does not persist it, making the purpose distinct.

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 use context: extracting profiles for marketplace discovery. It explicitly points to update_form for persistence, giving an alternative and next step. However, it doesn't explicitly state when not to use this tool or mention other alternatives, so it falls short of a 5.

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?

Annotations already declare readOnlyHint=true, so the read-only nature is covered. The description adds the connection-scoping behavior, which is useful, but it doesn't disclose error handling, response format, or pagination. With annotations present, this is adequate but not rich.

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, direct sentence with no filler words. It front-loads the action and scope efficiently.

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 list tool with read-only annotation and one parameter, the description is functional but doesn't mention return values, edge cases, or what fields are included in the base objects. Since there is no output schema, a bit more detail on results would be helpful.

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 has 0% description coverage for the single parameter connectionId. The description indirectly explains the parameter's role by mentioning 'connection', but doesn't provide details about ID format, source, or requirements beyond the schema's 'required' field. It partially compensates but not fully.

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 it lists Airtable bases for a given connection, using a specific verb and resource. It distinguishes from sibling list tools like list_connections and list_integrations by naming the resource type.

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 phrase 'available to a connection' provides clear context that a connectionId is required and the tool is scoped to that connection. While it doesn't explicitly mention alternatives or exclusions, the usage context is clear enough for an agent to know when to invoke it.

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?

Annotations already declare readOnlyHint=true and destructiveHint=false. Description adds that the tool returns merchant counts and covers all marketplace categories, providing useful context beyond the annotations. No contradictions.

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, immediately states action and output, with a use-case pointer. No filler.

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, read-only listing tool without an output schema, the description adequately covers purpose, output, and usage 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?

Tool takes no parameters; schema coverage is vacuous. Description naturally doesn't need to explain parameters. Baseline 4 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 uses a specific verb ('list') with a clear resource ('service categories') and scope ('all available on the Dashform marketplace'), and adds output detail ('merchant counts'). It clearly distinguishes from related search tools by positioning it as a precursor to searching.

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?

States when to use: 'before searching' to understand available service types. Does not explicitly name alternative tools, but the guidance is clear for a simple category listing.

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?

Annotations already declare readOnlyHint=true, so the description is consistent with a safe read operation. It adds minor context about active organization and provider filter, but no deeper behavioral traits such as pagination, limits, or ordering. There is no contradiction with 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 two sentences long, front-loaded with the action, and contains no unnecessary words. It earns its place by covering the core function, scope, and optional filter in a compact form.

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-only list tool with one optional enum parameter, the description covers the essential aspects: what it lists, where (active organization), and filtering. No output schema exists, but the return semantics are straightforward for a 'List' operation. The main gap is the lack of distinction from list_integrations, which is a contextual completeness issue.

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 description clarifies that 'provider' is an optional filter and provides examples of valid values, compensating for the schema's lack of descriptive text. Combined with the enum in the schema, the parameter is well understood despite the reported 0% schema description 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 tool lists integration connections in the active organization, with a specific verb ('List') and resource type. However, it does not distinguish this from the sibling tool 'list_integrations', which appears to serve a similar function. The examples (webhook, Slack, HubSpot) help clarify the concept but not the 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 context (active organization, optional provider filter) but gives no explicit guidance on when to use this tool versus alternatives like list_integrations or get_connection. Usage is implied rather than explicitly stated, leaving the agent to infer the appropriate scenario.

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?

Annotations already declare readOnlyHint=true, so the read-only nature is covered. The description adds behavioral context by scoping to the active organization and including status in the output, which is useful beyond annotations. For a simple list tool with no parameters, this is adequate transparency.

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 is front-loaded with the action and resource, and every word adds value (list, active organization, custom domains, status). There is no redundancy or filler.

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 params, no output schema, read-only annotations), the description covers all necessary aspects: what it lists, for which organization, and what information is returned (status). It is complete for its purpose, and no additional details are needed.

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, so the schema coverage is trivially 100%. There are no parameters to explain, and the description correctly adds no parameter-related details. The baseline for 0 params is 4, which is appropriate here.

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 a specific verb ('List') and resource ('custom domains of the active organization'), and mentions it returns their status. This unambiguously identifies the read-only list operation, distinguishing it from siblings like add_custom_domain, remove_custom_domain, and verify_custom_domain.

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 by specifying the active organization's scope and that it lists domains with status. Although it does not explicitly state when not to use it or reference alternative tools, the tool's unique listing role and context are evident, making the usage implied and clear.

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?

Annotations already declare readOnlyHint=true and openWorldHint=false, so the description does not need to restate safety. It adds behavioral context by mentioning response contents ('status and share/edit URLs') and supported features (search, sort, pagination), which go beyond the structured annotations. No contradiction exists.

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, focused sentences. The first sentence front-loads the core purpose and scope, the second lists capabilities. No filler or redundant information. Every word contributes meaning.

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 list tool with 5 optional parameters and no output schema, the description covers the essential aspects: scope (active organization), selected response fields (status, share/edit URLs), and functional capabilities (search, sort, pagination). It does not describe the full response structure, but the provided details are sufficient for an agent to invoke the tool correctly and set expectations.

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 only 40% (cursor and search have descriptions). The description partially compensates by stating 'Supports search, sort, and pagination,' which maps to the parameters, but it does not explain the exact semantics of sortBy/sortOrder or cursor beyond what the schema enums/defaults already provide. The conceptual link is there, but the low coverage leaves room for more.

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 ('List') with a clear resource ('forms') and scope ('in the active organization'). It distinguishes from sibling tools like get_form by implying a collection operation and adds output-specific details ('status and share/edit URLs'), making the purpose unambiguous.

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 clarifies the use case: listing forms in the active organization, with search/sort/pagination. It does not explicitly mention when not to use it (e.g., for a single form use get_form), but the context is clear enough to avoid confusion with other list_* tools. It could be improved by naming 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?

The annotation readOnlyHint=true already communicates safety. The description adds the scoping nuance that properties are 'available to a connection', which is useful context. It does not disclose pagination, error behavior, or what happens with an invalid connectionId, but for a simple read-only list that is a minor gap.

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, front-loaded sentence with zero fluff. It states the verb and resource immediately and includes the key scope qualifier. 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?

With only one parameter and no output schema, the description does not describe the return format (e.g., list of property metadata). It also does not clarify where connectionId comes from. This leaves the agent to infer expected output and parameter provenance from context, which is a notable gap.

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 0%. The description mentions 'a connection' but does not explain the connectionId parameter—its format, how to obtain it, or its role beyond the tool name. This fails to compensate for the schema's lack of detail.

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 ('List') and clearly identifies the resource ('HubSpot contact properties') plus a scope ('available to a connection'). This distinguishes it from sibling list tools like list_airtable_bases or list_connections.

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?

Usage is implied: the tool lists contact properties for a HubSpot connection. However, there is no explicit guidance on when to choose this over alternatives, no prerequisites, and no exclusion criteria. The 'available to a connection' phrase hints at its context but does not elaborate.

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?

Annotations already declare readOnlyHint=true, so the agent knows it's a safe read. The description adds that events are 'recent' and 'delivery', but it doesn't disclose ordering, pagination, or how events are filtered. Minimal extra context beyond what annotations provide.

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 is directly front-loaded with the verb and resource. It contains zero unnecessary words and is clear and efficient.

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?

The tool has no output schema, so the description should ideally explain what the response contains (e.g., event types, fields, pagination). 'Recent delivery events' gives a broad idea but leaves out specifics like ordering or return format, though the simplicity of the tool makes this minimally adequate.

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 0%, and the description does not elaborate on the 'integrationId' or 'limit' parameters. Although the parameter names and schema constraints (e.g., limit min/max) provide some clarity, the description fails to add any semantic value beyond 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?

The description uses a specific verb ('List') and resource ('recent delivery events for an integration'), which clearly distinguishes it from sibling tools like list_integrations (which lists integrations) and replay_integration_event (which operates on specific events). It precisely communicates the tool's function.

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 viewing recent delivery events but provides no explicit guidance on when to use this tool versus alternatives such as get_integration or replay_integration_event. There are no stated exclusions or preferred contexts, making the usage guidance merely implicit.

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?

The description does not disclose any behavioral traits beyond the function itself; it does not mention pagination, ordering, or what happens when no integrations exist. The annotations already declare readOnlyHint=true, so the read-only nature is covered, but the description adds no additional 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 sentence that is direct and front-loaded with the verb. No unnecessary words or repetition.

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?

The tool is simple, but the description is minimal. It does not clarify what an 'integration' is, what the response contains, or how this relates to sibling tools. Given the absence of an output schema and parameter descriptions, the description leaves notable gaps.

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% schema description coverage, the description must compensate for the undocumented formId parameter. It only implies that formId identifies the form via the phrase 'on a form,' without explaining the expected format or any constraints.

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 the specific verb 'List' and the resource 'integrations' with the scope 'configured on a form.' This clearly distinguishes it from sibling tools like get_integration (singular) and list_integration_events, making the purpose unambiguous.

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 explicit guidance on when to use this tool versus alternatives such as get_integration or list_integration_events. The usage is implied by the name and the phrase 'on a form,' but no alternatives or exclusions are mentioned.

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?

Annotations already declare readOnlyHint=true, so the safety profile is covered. The description adds the context that the list is scoped to a connection, which is useful but minimal. It does not describe error handling, pagination, or what happens with invalid connections. With annotations present, this is acceptable but not rich.

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, front-loaded sentence that directly states the purpose without any filler or redundancy. 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?

The tool is simple with one parameter and no output schema. The description covers the core function and scope. While it does not detail the return shape, for a straightforward listing operation this is likely sufficient. It could mention that it returns a list of audiences, but the verb 'List' implies that.

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 0%, so the description must compensate. The only parameter, connectionId, is only vaguely referenced by the phrase 'available to a connection'. It does not explain how to obtain connectionId, its format, or any constraints. This is insufficient given the low 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 action ('List') and the specific resource ('Mailchimp audiences'), and scopes it to a connection. This distinguishes it from sibling tools like list_airtable_bases or list_slack_channels by naming the exact integration and object type.

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, nor any exclusions or prerequisites. It only says 'available to a connection', which hints at a prerequisite but offers no decision framework. No alternatives are mentioned.

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?

Annotations already declare readOnlyHint=true and openWorldHint=false, covering the safe-read aspect. The description adds the 'active organization' scope and 'per-form' granularity, but does not disclose return structure, pagination, or potential caveats. It is not contradictory to 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 a single, front-loaded sentence that is clear and to the point. Every word contributes value without any redundancy or fluff.

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?

With zero parameters and annotations providing safety context, the description is mostly complete for a simple list operation. However, the lack of an output schema and any mention of the return format or counts meaning leaves minor ambiguity, so slightly below a perfect score.

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, so the schema fully covers everything (100% coverage). Per the rubric, a baseline of 4 applies, and the description does not need to explain parameters that do not exist.

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 action ('List') and the resource ('per-form hot-lead counts'), scoped to 'the active organization'. It is distinct from sibling tools like list_forms or list_replies, which serve different purposes.

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 information is provided about when to use this tool versus alternatives, nor any exclusions or prerequisites. The description is purely declarative and lacks context for decision-making.

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?

Annotations provide readOnlyHint=true, so the description doesn't need to restate safety. It adds useful behavior beyond annotations: the output is scoped to the user's memberships and includes the role in each organization, plus a pointer to the related switching tool. This adds meaningful context beyond what annotations declare.

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 the main purpose. The first sentence states function and output details; the second instructs on the related action. Every word earns its place, with 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?

For a zero-parameter list tool with a readOnlyHint annotation and no output schema, the description is sufficiently complete. It explains what is listed, the scope, the included role information, and the main related action, making it easy for an agent to select and invoke correctly.

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 and schema coverage is 100% (trivially), so there are no parameters to document. The description's phrase 'all organizations' implies no filtering, which is consistent with the empty schema. A baseline of 4 is appropriate given no parameters.

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 the specific verb 'List' with resource 'organizations', clearly scoped to 'the authenticated user belongs to', and mentions the output includes 'their role in each'. This distinguishes it from sibling tools like switch_active_org by explicitly referencing that tool as an alternative.

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: 'List all organizations the authenticated user belongs to' and directs the user to 'Use switch_active_org to change which one MCP acts on.' This clearly states when to use this tool versus the alternative, fulfilling the dimension.

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?

Annotations already set readOnlyHint=true, so the read-only nature is known. The description adds meaningful behavioral context: the response is paginated and includes respondent data, status, and scoring verdict. This goes beyond the bare 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 two concise sentences, front-loaded with the core purpose and immediately followed by the return summary. Every word contributes, with no redundant or vague phrasing.

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 list tool with 3 parameters and no output schema, the description covers the essential purpose and return content. It does not mention ordering or default pagination behavior, but those details are partially captured by schema defaults. Overall adequate but not exhaustive.

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 67% with formId and cursor described, but limit lacks a description. The description merely hints at pagination without explaining parameter semantics (e.g., how limit/cursor work). It offers marginal added value over 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?

The description clearly states the action and resource: 'List replies for a form' with pagination. It distinguishes itself from siblings like get_reply (single reply) and get_replies_insights by specifying it returns respondent data, status, and scoring verdict for a list of replies.

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?

Provides clear context: use this tool to list replies for a form, with pagination. It does not explicitly name alternatives or exclusions, but the 'list' verb and the pagination note imply when it is appropriate compared to single-fetch or insights tools.

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?

Annotations already declare readOnlyHint=true, and the description adds scoping to a connection, which is useful context. However, no further behavioral traits such as pagination, rate limits, or error conditions are disclosed. Given the simple, safe nature of the tool and the presence of annotations, this is adequate but not enriched.

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, front-loaded sentence with no filler. It conveys the core action and scope in minimal words, earning a perfect conciseness score.

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 one-parameter, read-only list tool, the description covers the core action but omits return value structure (e.g., whether it returns channel names, IDs, or metadata) and any limiting or pagination behavior. Since there is no output schema, the description could have filled this gap but does not, making it partially incomplete.

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 0%, so the description must compensate for parameter meaning. It merely says 'available to a connection,' which only vaguely maps to the connectionId parameter, leaving the format, provenance, and accepted values undocumented. The parameter name is self-explanatory to some degree, but the description does not explicitly link it to a Slack connection or explain how to obtain a valid ID.

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 a specific verb ('List') and resource ('Slack channels available to a connection'), distinguishing it from sibling integration-specific list tools like list_airtable_bases and list_mailchimp_audiences. The scope is unambiguous.

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 explicit guidance on when to use this tool versus alternatives, nor does it specify how to obtain the required connectionId (e.g., via list_connections). The only implicit usage clue is that channels are tied to a connection, but no exclusions or alternative tool references are given.

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?

Annotations already declare readOnlyHint=true and openWorldHint=false, and the description's 'List' is consistent. The description adds no further behavioral details, such as whether inactive subscriptions are shown or how results are ordered, but given the simple read-only nature, 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?

The description is a single, concise sentence that directly states the action and scope. Every word earns its place; there is no redundancy or unnecessary information.

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 list operation with one parameter and no output schema, the description provides the essential scope (per-form) and clearly implies a list of subscriptions is returned. It lacks explicit return-structure details, but this is not critical given the simplicity and read-only annotations.

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 no parameter descriptions (0% coverage). The description's 'for a form' adds a relational meaning to formId beyond the name/type, but it does not elaborate on expected format or usage details. Some compensation is provided, though more would be better.

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 'List' with a clear resource 'Zapier webhook subscriptions' scoped to 'a form'. This distinguishes it from sibling tools like toggle_zapier_hook and delete_zapier_hook, and from general listing tools like list_connections.

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: you need a form ID and you want to see its webhook subscriptions. However, it does not explicitly mention when to prefer this over related alternatives (e.g., list_integrations, toggle_zapier_hook) or any exclusions.

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?

Annotations already declare readOnlyHint=true, and the description's 'Load' is consistent. No additional behavioral context is added—such as pagination, ordering, or error behavior—so the description meets the baseline without enriching what the annotations already tell us.

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 leads with the verb and resource. It contains no redundant words and is perfectly sized for its simplicity.

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?

With no output schema, the description should explain what the returned messages look like or whether they are paginated. It does neither, though the tool's low complexity (one parameter, read-only) reduces the impact. The gap is noticeable but not severe, making the description minimally adequate.

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 0%, so the description must compensate for the missing parameter semantics. However, it only repeats the parameter name ('reference ID') without explaining what a reference ID is, how to obtain it, or any format constraints. This adds minimal value over the raw 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 clearly states the action ('Load'), the resource ('messages of a chat'), and the required input ('reference ID'). It distinguishes this tool from siblings like 'get_chat' (likely chat metadata) and 'list_replies' (form replies), making the purpose unambiguous.

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 makes it obvious when to use this tool: whenever you need the messages for a specific chat. It provides no explicit alternatives or exclusions, but the context is clear enough for straightforward selection. It could have mentioned prerequisites (e.g., obtaining the reference ID) but does not, leaving a small gap.

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?

Annotations already declare readOnlyHint=false and idempotentHint=true, indicating a write operation that is idempotent. The description adds the semantic meaning of 'actioned' as 'followed up on' but does not disclose additional behavioral traits such as reversibility, side effects, or permissions. It does not contradict the annotations, but the added value beyond them is minimal.

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, front-loaded sentence with no redundant words: 'Mark a reply as actioned (followed up on).' Every part earns its place, and the parenthetical clarifies the term 'actioned' without bloating the 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 simple tool with one parameter, clear annotations (readOnlyHint=false, idempotentHint=true), and no output schema, the description sufficiently conveys the core purpose. It does not need to explain return values, and the context is complete for correct invocation.

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 100% description coverage for the single 'id' parameter, stating 'The reply ID'. The description does not add any further meaning to the parameter or explain how to obtain it, so it provides no additional value over 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 'mark' with a resource 'reply' and outcome 'actioned (followed up on)'. It clearly distinguishes this from sibling tools like create_reply, delete_reply, and get_reply by indicating a state change rather than creation, deletion, or 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 does not explicitly state when to use this tool or provide alternatives. The usage context is implied by the action (marking a reply after following up), but there is no direct guidance or exclusion criteria, so it falls to implied usage rather than explicit direction.

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?

Annotations already indicate idempotentHint=true and readOnlyHint=false, so the safety profile is known. The description adds the behavioral detail that it returns the updated reply, which is useful, but it does not disclose side effects like whether the reason is retained or how reset interacts with scoring history. With annotations present, the additional context is modest.

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?

One single sentence that front-loads the main verb and resource, immediately states the possible values, and ends with the return value. It is minimal but information-dense, with no filler.

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?

The tool is simple (2 parameters, one a discriminated union) and the schema thoroughly defines the action structure. The description covers the return value, and annotations cover idempotency and mutability. It lacks only an explicit tie to when overriding is appropriate, but for this complexity the description is sufficiently 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 coverage is only 50% (only 'id' has a description at the top level), and the description does not compensate by explaining the 'action' parameter or its set/reset variants. It mentions verdict values but does not link them to the parameter structure, leaving the agent to parse the schema alone.

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 ('set or reset') and the resource ('a reply's lead verdict'), while also specifying the possible values (hot/warm/cold) and the return value. This distinguishes it from siblings like rescore_form_replies, which likely automate scoring, and create_reply/delete_reply, which manage the reply itself.

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 word 'Manually' implies this is for overriding an automated verdict, which provides clear usage context. However, it does not explicitly name alternatives or state when not to use it, so it stops short of the highest rating.

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?

Annotations already indicate readOnly=false, so the agent knows this is a mutation. The description adds that the tool publishes the 'current draft' as a 'new live version', clarifying the state change. However, it does not disclose potential side effects such as overwriting an existing live version or permission requirements. No contradiction with 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 two sentences long, front-loaded with the core action and outcome, and contains no redundant wording. Every sentence contributes meaningful information.

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?

This is a simple single-parameter tool with no output schema. The description covers the core action, the draft-to-live transition, and a key prerequisite. It omits details like return value or overwrite behavior, but for a tool of this simplicity it is adequately 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?

The schema fully describes the only parameter 'id' as 'The form ID to publish' (100% coverage). The description does not add additional parameter semantics, but the schema carries the full burden, so a baseline score of 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 clearly states the action: publish the form's current draft as a new live version. It distinguishes this tool from siblings like update_form (which edits the draft) and get_published_form_version (which reads the live version). The added note that it is required before a form can receive replies further clarifies the tool's purpose.

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 usage context: publishing is required before a form can receive replies, implying it should be used after editing the draft. It does not explicitly exclude alternatives or mention when not to use it, so it stops short of a perfect score.

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?

The annotations already declare readOnlyHint=true, and the description aligns with that. It adds context that the tool inspects the backfill backlog, but it does not disclose output format or any other behavioral details (e.g., whether it fails if the backlog is too large).

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?

One concise, front-loaded sentence with no redundant words. Perfectly sized for the simple operation.

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 (one parameter, no output schema), the description covers the core purpose and timing. However, it does not describe the output or what the check returns, which is a gap since no output schema exists. The read-only annotation aids but does not fully compensate.

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% schema description coverage, the description needs to clarify connectionId. It says 'for a connection,' which confirms that connectionId identifies the relevant connection, but it adds no detail about format, source, or constraints. This is a modest compensation.

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 the specific verb 'Check' with the resource 'backfill backlog for a connection,' and the phrase 'before reconnecting it' gives a clear purpose. This distinguishes it from other connection-related tools like get_connection or delete_connection.

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 on when to use it: 'before reconnecting it.' However, it does not explicitly mention alternatives or exclusions, which keeps it from a 5.

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?

The readOnlyHint annotation already indicates a safe read operation, and the description adds that the tool returns the refined prompt text and is 'single-shot', providing useful behavioral context beyond what annotations offer. It does not contradict 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 two concise sentences with no unnecessary words. It is front-loaded with the action 'AI-refine' and clearly states the output, making every word earn 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?

For a simple two-parameter tool, the description covers the basic purpose and output, but it lacks parameter semantics and any mention of edge cases or return structure. Since there is no output schema, the description could have provided more detail about the refined prompt format or examples, but overall it is minimally adequate.

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 description coverage is 0%, and the description only vaguely references 'funnel type' and 'form-building prompt'. It does not explain the meaning of the parameters, the valid enum values, or how the refinement process uses them, leaving the agent to infer from parameter names alone.

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 refines a form-building prompt for a given funnel type and returns the refined text as a single-shot output. It distinguishes itself from siblings, as no other tool is specifically for prompt refinement.

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 when a form-building prompt needs AI refinement, but it does not explicitly state when to use this tool versus alternatives or provide exclusions. The mention of 'funnel type' gives some context, but no direct comparison to other tools.

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?

Beyond the annotations (destructiveHint=true, idempotentHint=true), the description adds a critical permission requirement ('Owner only') and a confirmation step ('Pass confirm: true to proceed'), giving the agent actionable safety context. It does not contradict the 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 two concise sentences, front-loaded with the action and scope, followed by essential usage and safety details. Every word earns its place, with no unnecessary verbosity.

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 one-parameter mutating tool with strong annotations and no output schema, the description covers the essential usage, permission, and confirmation requirements. It could optionally mention that the key must already exist, but this is not necessary for the agent to invoke the tool correctly.

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 already documents the single parameter 'confirm' with a description 'Must be true to remove', and schema coverage is 100%. The description's 'Pass confirm: true to proceed' adds little beyond restating the schema's meaning, so the baseline of 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 states a specific verb ('Remove') and a specific resource ('the active org's BYOK AI provider key'), clearly distinguishing it from sibling tools like save_ai_provider_key and get_ai_provider_status. The scope is also specified ('active org'), leaving no ambiguity about what the tool does.

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 usage context by stating 'Owner only' as an access prerequisite and instructing to 'Pass confirm: true to proceed'. While it does not explicitly mention when to use it instead of the save/get variants, the name and verb make the use case obvious, and the owner/confirm guidelines are 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?

Annotations already declare destructiveHint=true and readOnlyHint=false. The description adds valuable behavioral context beyond annotations: the authorization requirement (owner/admin only), scope (active org), and confirmation guard (confirm: true). This is useful but does not elaborate on irreversibility or side effects beyond what the annotations imply.

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, front-loaded with the core purpose, and every clause adds significant information (scope, permission, confirmation). 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 destructive tool with two parameters, no output schema, and good annotations, the description covers the essential aspects: what it does, scope, authorization, and confirmation requirement. It does not mention return values or details about the removal process, but these are likely self-evident given the annotations and simple parameter set.

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 50%, with only confirm having an inline description. The description reinforces the meaning of confirm ('Pass confirm: true to proceed') but does not clarify what id represents beyond the obvious 'custom domain' context. Since id is required and ambiguous, the description only partially compensates for the schema gap.

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 ('Remove') and resource ('custom domain') and further scopes it to the active org, clearly distinguishing it from sibling tools like add_custom_domain, list_custom_domains, verify_custom_domain, and set_custom_domain_default_form.

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 use: it applies to the active org, requires owner/admin permissions, and mandates confirm: true to proceed. However, it does not explicitly mention alternatives or when not to use this tool, stopping short of a 5.

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?

Annotation contradiction: annotations set openWorldHint=false, but the description's 're-enqueue ... integration delivery event' implies triggering an external delivery, which is a real-world side effect. The description does not disclose this behavior, and it conflicts with the annotation. readOnlyHint=false is consistent with the mutating nature, but openWorldHint=false contradicts the concept of replaying a delivery.

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, concise sentence that is front-loaded with the action. It contains no superfluous words and is appropriately sized for the simple tool.

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?

The tool has a single parameter and no output schema, but the description is incomplete due to the annotation contradiction. It does not clarify the external delivery side effect, nor does it mention any prerequisites (e.g., event must exist). Given the openWorldHint conflict, the agent cannot accurately predict the tool's impact.

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 0% and the description does not explain the eventId parameter. The parameter name is somewhat self-explanatory (an event ID), but the description adds no detail about what constitutes a valid eventId or how to obtain one. This is a minimal compensation for the lack of schema descriptions.

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 action: 'Re-enqueue a failed or past integration delivery event.' It uses a specific verb ('re-enqueue') and identifies the resource ('integration delivery event'). It distinguishes from sibling tools like list_integration_events (listing events) and create_integration (creating integrations).

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 failed or past delivery events, giving some context, but it does not explicitly state when to use this tool versus alternatives (e.g., list_integration_events for inspection). It lacks exclusion criteria or alternative tool references.

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?

Annotations already indicate it is not read-only, so the mutation nature is clear. The description adds the return value (count of replies marked for scoring), but does not disclose whether prior scores are overwritten, whether the operation is asynchronous, or any other side effects.

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 sentences with no filler; the action and return are front-loaded. Highly concise and easy to parse.

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 tool with no output schema, the description gives the return value, but lacks details about idempotency, side effects, and whether there are any preconditions (e.g., form must already have scoring configured). Given the sibling context, more operational context would help.

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 only parameter, formId, is referenced by 'a form's replies,' making its purpose clear despite 0% schema coverage. However, no additional constraints or format details are provided, and the description adds minimal nuance beyond the parameter name.

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 the specific verb 'Re-run' with a clear resource ('AI lead scoring across a form's replies'), and it distinguishes the tool from siblings like update_scoring_criteria or override_verdict by focusing on bulk rescoring. The action and target are unambiguous.

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