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

No annotations are present, so the description carries the burden. It discloses the return statuses, result count, full results on completion, and the polling behavior. This is transparent for a simple poller, though it omits edge cases like invalid job IDs or error handling details.

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, front-loaded with an action verb and concise details on returns and workflow. No filler or redundant 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?

Since there is no output schema, the description explains what the tool returns (status, result count, full results) and delineates the polling loop and subsequent tool to call. This is complete for a single-parameter 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 coverage is 100% (job_id described as 'Research job ID from run_research'). The description adds context about the polling loop but does not add new parameter details beyond what the schema already provides, so the baseline score of 3 applies.

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

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

The description clearly states the tool polls the status of a running research job, listing specific statuses and return values. It distinguishes itself from sibling tools like import_research_results by framing the polling action and what to do after.

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 guidance: 'Keep calling this until status is complete, then call import_research_results.' This tells when and how to use it in the workflow, though it does not mention when not to use or alternatives.

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

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

With no annotations, the description carries the burden. It discloses the key behavioral trait that campaigns are created as drafts and require a separate activation step. It does not mention permissions, idempotency behavior, or response format, but the draft state is the most important side effect and is clearly stated.

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 primary action, and every sentence earns its place by adding context on draft status and alternatives. No waste.

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

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

Given no output schema and no annotations, the description covers the essential context: creation, draft state, activation step, and pilot alternative. It lacks details on return values or config specifics, but the schema covers config, and the core workflow is clear. Slightly more detail could make it 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 100% with all parameters already described in the input schema. The description adds no additional parameter-level detail, which is acceptable given the high schema coverage.

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

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

The description clearly states the tool creates a new campaign, distinguishes it from update_campaign_status (which activates) and pilot (which builds AI-generated campaigns), and specifies it creates as a draft. This is a specific verb+resource with clear sibling differentiation.

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

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

Explicitly instructs to use update_campaign_status to activate after creation and offers pilot as an alternative for fully AI-built campaigns. This gives direct when-to-use and when-not-to-use 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?

With no annotations, the description carries full responsibility for behavioral disclosure. It only states the action 'create' and provides no information about side effects, permissions, or special behaviors like upsert or idempotency, which are defined in the schema but never surfaced. This is a complete lack of 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 extremely concise at one sentence with no wasted words, but it is so brief that it misses opportunities to convey useful context without bloat. It earns a 4 rather than a 5 due to the lack of value-added 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?

The tool has 3 parameters including an upsert flag and idempotency key, which are behaviorally significant. The description makes no mention of these features, nor does it describe return values or error conditions. With no output schema and no annotations, the description is incomplete for a tool with this 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?

The schema has 100% description coverage, so all parameters are already well-documented. The description adds no additional meaning beyond the schema, 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 'Create a company account in the CRM' uses a specific verb and resource, making the primary purpose clear. However, it does not differentiate from sibling tools like create_contact or create_webhook, which share the same 'create' pattern.

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 on when to use this tool versus alternatives, nor are any prerequisites, exclusions, or typical use cases mentioned. The description is purely declarative and leaves the agent without selection criteria.

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

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

With no annotations, the description carries the burden of disclosing side effects. It discloses auto-creation of companies and optional campaign enrollment, but does not mention the upsert behavior (updating vs duplicate error) or idempotency semantics, which are significant behavioral traits.

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 action, and every sentence adds meaningful context. No fluff 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?

The description covers the main purpose and two side effects, but omits important context like duplicate handling, upsert behavior, and return values. Given the tool's complexity (4 params, nested array) and lack of annotations/output schema, more detail would improve completeness.

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

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

Schema description coverage is 100%, so baseline is 3. The description adds minimal value beyond the schema: it restates campaign enrollment and company creation, but these are already described in the property descriptions. No additional parameter meaning is provided.

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

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

The description clearly states the action (create), the resource (contacts), and the scope (one or more). It also distinguishes itself from sibling tools by mentioning automatic company creation and campaign enrollment, which are unique behaviors.

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 (creating contacts) and gives context that company creation is handled automatically, but it does not explicitly compare with alternatives like create_company or update_contact. No direct 'use this instead of X' 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?

With no annotations, the description carries the burden for behavioral transparency. It explicitly discloses the idempotent behavior of returning an existing folder on name collision, which is valuable beyond the schema. It does not mention permissions or side effects, but for a simple create operation this is adequate.

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 clear, front-loaded, and contains zero filler. Every phrase adds value, including the idempotency note.

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 creation tool with two well-described parameters and no output schema, the description provides enough context: it names the resource, the idempotent behavior, and the return behavior on conflicts. It lacks an explicit statement of what a successful creation returns, but the description's mention of 'returns the existing one' implies the return of a folder object.

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

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

Schema coverage is 100%, and both parameters have clear descriptions. The description adds meaning by linking the 'name' parameter to the idempotent duplicate-handling behavior, which is not present in the schema. This elevates it above the baseline 3.

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 'Create' and the specific resource 'contact folder', distinguishing it from sibling tools like create_contact. It also adds the unique idempotent behavior of returning the existing folder, which fully clarifies its 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 implies when to use this tool (to create a folder) and clarifies behavior on duplicate names, which is useful for agents deciding whether to call this or list_folders first. It does not explicitly name alternatives, 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?

Since there are no annotations, the description carries the full burden of disclosing behavioral traits. It adds useful context (HTTPS requirement, real-time notifications) but omits important details such as what the function returns, permission prerequisites, or any rate limits, limiting its 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 highly concise and front-loaded. Two sentences convey the registration purpose and the HTTPS requirement without any 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?

With no output schema and no annotations, the description lacks essential context about what the tool returns (e.g., webhook ID) and what happens after successful registration. For a tool with four parameters and no structured output details, this is a significant 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?

The input schema already contains complete descriptions for all four parameters, achieving 100% schema description coverage. The description introduces no additional parameter meanings, 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 action ('Register a webhook') and its purpose ('receive real-time event notifications'), making it distinct from sibling tools such as list_webhooks and delete_webhook. The verb and resource are specific and 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 guidance on when to use this tool compared to alternatives like list_webhooks or delete_webhook. It only states a technical constraint (HTTPS URL) but lacks any contextual direction about when registration is appropriate.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It explicitly states the action is 'Permanently' destructive and describes the side-effect that linked contacts are 'unlinked but not deleted.' This is valuable behavioral context, though it could also mention the confirmed flag requirement, which is in the schema.

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 with no redundancy. The first sentence delivers the core purpose, and the second adds a critical side-effect in a clear, front-loaded manner.

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, combined with the schema's detailed parameter documentation, provides sufficient context for safe usage. It covers irreversibility and side-effects, making the tool adequately understandable. The confirmation flag is documented in the schema, so the description does not need to repeat it.

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

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

The schema has 100% description coverage for all three parameters, so the description does not need to add parameter-level details. It does not discuss parameters, but the schema already provides full meanings. 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 'Permanently delete a company account from the CRM' with a specific verb and resource, distinguishing it from sibling tools like delete_contact by focusing on company accounts. It also explains the effect on linked contacts, further clarifying its unique 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 clear context that this tool is for deleting a company, with no ambiguity about its use case. It mentions the unlink side-effect, but does not explicitly name alternatives or when-not-to-use scenarios. The context is apparent given the tool name and description.

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

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

No annotations are provided, so the description carries the full burden. It discloses the permanent, irreversible nature of the deletion, which is critical behavioral information. It does not mention the required confirmation parameter, but that is covered in the schema.

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, directly to the point, with no filler. The description earns every word.

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 paired with the schema provides sufficient information for a destructive operation, including permanence and the confirmation flag. It lacks explicit alternatives or consequence handling, but for a simple delete tool this is 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 100% with each parameter described. The description adds no parameter-specific details beyond mentioning the ID, so the baseline of 3 applies.

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

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

The description states 'Permanently delete a contact from the CRM by its ID', using a specific verb and resource, and clearly distinguishes from sibling tools like update_contact or create_contact.

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 when a contact must be permanently removed, and the warning 'This cannot be undone' signals caution. However, it does not explicitly compare with alternatives or state conditions 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?

With no annotations provided, the description carries full responsibility for disclosing behavioral traits. It does not mention that the action is destructive, irreversible, or that the 'confirmed' parameter must be true to succeed. The description only states the action without any safety or side-effect 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, complete sentence with no filler words. It front-loads the action and resource, effectively serving its purpose without any 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 destructive operation with no annotations and no output schema, the description is too sparse. It fails to convey the irreversible nature of the deletion, the confirmation requirement, or any other behavioral context that a safer delete tool should communicate. The schema offers some detail, but the description itself leaves significant 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?

Schema description coverage is 100%, so the baseline is 3. The description itself adds no parameter information beyond what the schema already provides, but the schema fully documents each parameter's purpose, including the need for 'confirmed' and the optional 'idempotency_key'.

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 'Remove' and identifies the resource as 'webhook subscription' with the method 'by its ID'. This clearly distinguishes it from sibling tools like list_webhooks and create_webhook, leaving no ambiguity about its 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 provides no guidance on when to use this tool versus alternatives, nor does it mention prerequisites or exclusion conditions. It simply states the action, leaving the agent to infer usage entirely from the tool name and schema.

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

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

No annotations are provided, so the description carries the burden of disclosing behavioral traits. It only lists returned data and does not state whether the operation is read-only, requires special permissions, or has other side effects, leaving safety assumptions unconfirmed.

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, clear sentence that front-loads the verb and resource, with no unnecessary words or repetition. It is appropriately sized for the tool's 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?

For a simple one-parameter get tool with no output schema, the description provides a reasonable overview of return contents (config, steps, audience statistics). It could be more complete by describing the return format, but it sufficiently covers the tool's purpose and scope.

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 complete description (100% coverage) for the single parameter campaign_id, so the baseline is 3. The description does not add additional semantic detail beyond what the schema already specifies.

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 a single campaign's full details, including config, steps, and audience statistics. This distinguishes it from siblings like get_campaign_status, but does not explicitly name alternatives.

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 full campaign details are needed, contrasting with list_campaigns or get_campaign_status. However, it lacks explicit when-not-to-use guidance or named 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?

No annotations are provided, so the description must convey the tool's safety and side effects. The verb 'Get' and the wording 'Returns...' clearly indicate a read-only operation, and the specific metrics listed foreshadow the output. It does not disclose potential errors or rate limits, but for a simple read tool, this level is adequate.

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 concise sentences, front-loaded with the verb and resource, and zero wasted words. 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?

This is a simple one-parameter read tool with no output schema. The description clearly explains what is returned and enumerates the specific counts. No additional context is necessary 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?

The input schema has 100% coverage for the only parameter (campaign_id) with a clear description. The tool description does not add extra meaning beyond the schema, but the baseline of 3 is appropriate when schema coverage is complete.

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

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

The description uses a specific verb ('Get') and resource ('status and audience statistics of a campaign'), and enumerates the exact metrics returned (enrolled, active, completed, paused, bounced, failed). This clearly distinguishes it from siblings like get_campaign (broader details) and list_campaigns (listing campaigns).

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 indicates the tool's purpose—retrieving status and audience statistics for a campaign—which implies when to use it. However, it does not explicitly mention alternative tools or exclusion criteria, 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?

No annotations are provided, so the description must carry the behavioral burden. It adds that the tool returns 'all fields' and lists examples, which is useful, but it does not disclose whether this is a safe read-only operation, error behavior, or authorization requirements. The 'Get' verb implies read-only, but this is not explicit.

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, no redundant words. Every phrase adds value: the first sentence defines the action and scoping, the second clarifies the return payload.

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 single-parameter GET operation with no output schema, the description covers the essential aspects: what it does, the input, and the return shape (field list). It could mention not-found handling, but given the simplicity, it's largely 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 input schema already provides 100% coverage for the single parameter company_id with a clear description. The description's 'by its ID' adds no additional semantic meaning 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 the specific verb 'Get' with the resource 'a single company account by its ID', clearly distinguishing it from sibling tools like list_companies, create_company, and update_company. It also specifies the returned fields, reinforcing its 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 implies the use case (fetching a specific company by ID) but does not explicitly state when to prefer this over alternatives like list_companies or search_contacts. No exclusions or alternative tool references are provided.

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

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

No annotations are provided, so the description carries the full burden. It discloses the return behavior by listing the fields returned (email, phone, LinkedIn URL, etc.), which is useful. It does not mention error handling or existence checks, but for a read operation this is acceptable.

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

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

The description is a single, front-loaded sentence that states the action first and then clarifies the return content. 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?

With only one required parameter and no output schema, the description provides sufficient context: it specifies what is returned (all fields) and gives concrete examples. This is complete for a simple get-by-ID 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 100% for the single parameter, describing it as 'ID of the contact to retrieve.' The description adds no additional meaning beyond 'by its ID,' so it matches the baseline of 3.

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' with a clear resource 'a single contact' and method 'by its ID'. It distinguishes itself from siblings like list_contacts and search_contacts by emphasizing single-contact 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 usage when you have a contact ID, but it does not explicitly state when to use this tool instead of siblings like search_contacts or list_contacts. No exclusion or alternative is 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?

No annotations are provided, so the description carries the full burden. It clearly implies a read-only status check and lists the information returned, but it does not explicitly state that checking does not consume credits or note any authentication requirements. Still, for a simple balance lookup, it provides adequate behavioral 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 two sentences and immediately states the purpose. The second sentence adds actionable guidance without any filler or repetition. It is front-loaded 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?

Despite lacking an output schema, the description thoroughly explains the return values (balance, limit, tier, reset time) and the practical use case. For a zero-parameter read-only tool, this is complete and leaves no major 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 tool has zero parameters, and the schema coverage is trivially 100%. The description adds value by explaining what kind of information the tool returns, which compensates for the absence of parameters. Per rubric, zero-parameter tools receive a baseline of 4.

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

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

The description uses a specific verb ('Check') with a clear resource (credit balance) and lists the exact data points returned: current balance, monthly limit, plan tier, and reset time. It is clearly distinct from sibling tools, none of which deal with credits or billing.

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 guidance on when to use the tool: to verify sufficient credits before launching research or campaigns. It does not mention alternatives or exclusions, but since no sibling tool appears to cover credit info, this is clear enough.

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

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

With no annotations, the description carries the burden of disclosing side effects. It mentions the precondition and optional effects (folder/campaign assignment), but does not mention the confirmation requirement, idempotency behavior, or potential for duplicates. This provides some transparency but leaves important behavioral aspects unstated.

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

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

The description is two sentences, front-loaded with purpose and immediately followed by a critical precondition. Every word earns its place; 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 tool with 5 parameters and no output schema, the description covers the essential context: what it does, when to call it, and optional behaviors. However, it omits mention of the 'confirmed' parameter and idempotency, which are important for safe usage, so it is not fully complete.

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

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

The schema provides 100% coverage of parameter descriptions, so the baseline is 3. The description references folder_name and campaign_id via 'auto-assign to a folder and/or enroll in a campaign', but this only restates what the schema already explains. No additional semantic value is added.

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 ('Import completed research results into the CRM as contacts') with a specific verb and resource. It distinguishes itself from siblings like create_contact (manual single contact) and run_research (produces the results), making its role unique.

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?

It explicitly states a precondition: 'Only call after check_research_status returns complete', which provides clear when-to-use guidance. It also hints at optional features (auto-assign folder/enroll campaign) but does not explicitly mention alternatives like create_contact for individual import, so a 4 is appropriate.

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

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

With no annotations provided, the description carries the burden of disclosing behavioral traits. It indicates a read-only listing operation, but does not mention pagination behavior, default limits, ordering, or whether all campaigns or only those owned by the user are returned. This leaves gaps in what the agent can expect, so a mid-range score 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 two tight sentences with the main action front-loaded. 'List your outreach campaigns' immediately answers what it does, and the second sentence adds useful filtering context. Every word earns its place without 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 list tool with 4 parameters and no output schema, the description covers the core purpose and filtering capability. It does not mention pagination details or response format, but these are partially inferred from the schema and the verb 'list'. Slightly more detail on scope or return shape would make it fully complete, but it is adequately informative as is.

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 covers all 4 parameters with descriptions (100% coverage), so the baseline is 3. The description repeats 'status' and 'type' but adds no extra semantic meaning beyond what the schema already provides, and does not mention limit/offset at all. It neither enhances nor detracts from 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 'List your outreach campaigns' with a specific verb and resource, distinguishing it from sibling list tools like list_contacts or list_companies. It also clarifies the scope ('your') and mentions filtering, which differentiates it from get_campaign for single 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 phrase 'Filter by status or type to find active, draft, or paused campaigns' provides clear context on when to use this tool (to search/filter campaigns). However, it does not explicitly state when not to use it or mention alternatives like get_campaign for single-campaign retrieval, so it falls 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?

With no annotations provided, the description carries the full burden for behavioral disclosure. It only states the listing action and a data model fact about linking to contacts, but does not disclose return format, pagination behavior, or any limitations. This is insufficient for a tool with no 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 short sentences with the main purpose front-loaded. It is appropriately sized and free of redundant content, though the second sentence adds marginal 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?

The description is minimal and does not explain what the response looks like, given there is no output schema. It does not mention ordering, field selection, or how parameters combine, making it incomplete for an agent relying solely on the description.

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% coverage with descriptions for all four parameters, so the description adds no additional parameter meaning. Baseline is 3 because the schema already documents limit, domain, offset, and search.

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 company accounts in the CRM with a specific verb and resource. It is distinct from sibling tools like get_company (single company) and create_company/delete_company.

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

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

The description provides no guidance on when to use this tool versus alternatives like get_company or search_contacts. It lacks any exclusions or alternative recommendations, leaving the agent to infer usage 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?

With no annotations provided, the description must disclose behavioral traits. It states 'List all contacts' and 'paginated browsing,' which implies a read-only operation with pagination. However, it does not explicitly mention that it has no side effects, nor does it describe the return format or any rate limits. Since 'list' is inherently non-destructive, it gains some credit, but the description could be more transparent about behavior beyond what is obvious from the name.

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 purpose, followed by a clear alternative and use case. No filler or redundancy. Every sentence earns its place, making it appropriately sized and well-structured.

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 optional parameters and no output schema or annotations. The description covers the main purpose, alternative, and use case, but does not mention return value or pagination specifics (beyond 'paginated browsing'), which are common expectations. Still, for a simple list tool with well-described parameters, the description is reasonably complete. A small gap is the lack of any note about ordering or default 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?

The input schema has 100% coverage with descriptions for all parameters (limit, offset, status, folder_id). The description merely says 'optional filters' without adding any meaning beyond what the schema already provides. This matches the baseline of 3, as the schema does the heavy lifting and the description adds no extra 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's function: 'List all contacts in your CRM with optional filters.' It specifies the resource (contacts) and the action (list), and distinguishes itself from the sibling tool search_contacts by noting that search_contacts is for keyword search. This is a specific verb+resource with clear scope.

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 naming an alternative: 'Use search_contacts for keyword search.' It also states the intended use case: 'This is for paginated browsing,' which tells the agent when this tool is appropriate. This is an explicit when/alternative distinction, matching the highest 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?

With no annotations, the description carries the full burden of behavioral disclosure. It states the return fields (names, IDs, contact counts) but does not disclose behaviors like default ordering, pagination limits, or error conditions. The description is not misleading, but it is minimal for a tool without annotation support.

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, with no filler. The first sentence is front-loaded with the verb and resource, and the second sentence adds relevant context about folder purpose and return values. 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 list tool with no output schema, the description explains the tool's purpose, the organizational role of folders, and the return fields. It is sufficient for an agent to understand the tool's function. It lacks explicit details about pagination behavior or sorting, but given the simplicity, it reaches a 4.

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 covers both parameters (limit and search) with clear descriptions and defaults. The description does not add additional meaning about parameter usage or syntax beyond what the schema already provides. With 100% schema coverage, 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 starts with a clear verb and resource: 'List all contact folders in the workspace.' It distinguishes from siblings like list_contacts and search_contacts by specifying the resource (folders). The additional context about folders organizing contacts for campaigns clarifies the 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 implies when to use the tool by mentioning that folders organize contacts for campaigns, but it does not explicitly state when to prefer this over alternatives like list_contacts or search_contacts. No exclusions or alternative tools are named, so the guidance is only implied.

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

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

With no annotations, the description carries full burden. It discloses the read-only nature ('List') and the 'active' filter, but lacks details on pagination, response format, or authentication. The second sentence educates about webhooks but does not reveal additional behavioral traits beyond the core listing action.

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, front-loaded with the main action, followed by a succinct explanatory note. Every word earns its place with 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?

For a simple zero-parameter read-only tool, the description is adequate. It explains what it lists and provides background on webhooks. However, it does not describe the return structure (e.g., arrays of webhook objects) or the meaning of 'active' in more detail, and there is no output schema to 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?

The tool has zero parameters, so the description does not need to explain parameter meanings. The schema coverage is trivially 100% with an empty object. The description adds no parameter info, but none is required, warranting the baseline 4.

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

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

The description clearly states the action ('List') and the resource ('active webhook subscriptions'), distinguishing it from sibling tools like create_webhook and delete_webhook. The addition of example event types adds context without obscuring the primary 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 usage is implied: to see existing webhook subscriptions. However, it does not explicitly contrast with create_webhook or delete_webhook, nor does it state when to use this tool in favor of others. The context is clear but not fully explicit.

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

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

No annotations are provided, so the description carries the burden. It discloses that the tool 'Returns a detailed walkthrough' and enumerates covered topics, but it doesn't explicitly state that it has no side effects or mutations. Adequate for a read-only guide.

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 a useful enumerated list of content areas. 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 informational tool with one optional parameter and no output schema, the description covers the purpose, content areas, and usage context. 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 sole optional parameter 'focus' is fully documented in the schema with options and default (100% coverage). The description doesn't add extra parameter context, 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 'Get the step-by-step onboarding guide for setting up OutreachPilot from scratch' with a specific verb and resource. It distinguishes from sibling tools by being the only onboarding/setup guide among data operations.

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

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

The description explicitly says 'Use this when a user is new or asks how to get started,' providing clear context. It doesn't mention exclusions, but none are necessary given the tool's informational nature.

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

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

No annotations are provided, so the description must carry the transparency burden. It says 'execute it using its full toolkit' and includes examples of mutating actions (e.g., 'Send a LinkedIn connection request', 'Book a meeting', 'Pause my cold email campaign'). However, it does not explicitly disclose potential side effects, reversibility, or that actions will have real-world consequences. This is a moderate disclosure 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 long but well-structured with an opening summary, a clear usage directive, and categorized bullet examples. Every section adds practical value for an agent. It is not bloated with unrelated content, and the organization makes it easy to scan.

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 complex tool with no output schema and no annotations, the description thoroughly covers use cases and scope, which is critical. However, it omits any information about return values/response format, error handling, or potential limitations. Since there is no output schema, the description should have provided some indication of what the agent can expect in response.

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 describes 'message' as 'Natural language instruction' and 'thread_id' as optional context. The description adds substantial value by providing a large set of concrete example instructions across domains, enriching the semantics of the message parameter beyond the schema. It does not discuss thread_id, but the coverage is already high and the examples more than compensate.

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 'The OutreachPilot AI engine. Send any natural language instruction and Pilot will execute it using its full toolkit.' This clearly states a specific verb (execute), resource (full toolkit), and differentiates from simple CRUD siblings by stating 'beyond simple CRUD.'

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

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

The description explicitly says 'Use this for complex or multi-step tasks that go beyond simple CRUD.' This provides clear guidance on when to use the tool versus the specific sibling CRUD tools. The extensive categorized examples further illustrate the appropriate contexts without ever being vague.

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

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

With no annotations provided, the description carries full behavioral disclosure. It reveals the async job nature, the required two-step confirmation, and the polling requirement via check_research_status. This is substantial context beyond what the schema provides.

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, front-loaded with the main action, and every sentence earns its place. No redundant phrases.

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?

Covers the async job execution, job_id return, polling, and the confirmation workflow. However, it doesn't describe what the results will look like (though that may be delegated to check_research_status) or cost estimate details, leaving minor ambiguity given there is no output schema.

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

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

Schema coverage is 100% for all 6 parameters, so the baseline is 3. The description reinforces the confirmed=false-first workflow, but this is already clearly documented in the schema, so it adds little new parameter-level 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 clearly states the tool starts an agentic research job to find companies or people. It distinguishes itself from the sibling check_research_status by noting it returns a job_id to poll, making its role in the workflow explicit.

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 a clear two-step usage sequence: send with confirmed=false for a cost estimate, then confirmed=true to execute. While it doesn't explicitly name alternatives or when not to use, the workflow is very specific and actionable.

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

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

No annotations are provided, so the description carries the full burden. It discloses that it returns matching contacts with specific fields, which is useful. However, it does not describe potential side effects (none expected), pagination behavior, or any limitations beyond the schema. This is a minimal viable disclosure but lacks depth.

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 followed by the return value summary. 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?

The tool has no output schema, so the description correctly and sufficiently explains the return fields. It covers the main parameters (query, limit, filters are in schema) and the core functionality. Minor gaps include no mention of default ordering or behavior on no matches, but these are not critical for a straightforward search tool.

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

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

The schema description coverage is 100%, so the baseline is 3. The description adds no additional parameter context beyond what the schema already provides—query, limit, status, and folder_id are already clearly described. The description's mention of searchable fields (name, email, company) mirrors the schema text.

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 searches the OutreachPilot CRM for contacts by name, email, or company, and specifies the return fields (status, email, LinkedIn URL, creation date). This is a specific verb+resource+scope that distinguishes it from sibling tools like list_contacts or get_contact.

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 the use case: when you need to search contacts by a query. It does not explicitly mention alternatives or exclusions, but the context is clear enough that an agent would know when to use this tool. No explicit 'use list_contacts instead' guidance, but the search intent is obvious.

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

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

With no annotations, the description bears the full burden of behavioral disclosure. It mentions the cost of 1 credit per send and that it uses the connected email account, but it does not disclose the confirmation flag required to actually send, potential irreversibility, or error behaviors. It adds some value but lacks depth for a mutation with 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 purpose, and includes critical cost and alternative information in a compact form. 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 send operation with 100% schema coverage, the description provides essential context (cost, one-off scope, alternate tool for bulk). It does not describe the return value, but no output schema exists, and the core behavior is adequately covered. Missing a direct mention of the confirmation requirement, but that is fully documented in the schema, so not a critical 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 100%, so the baseline is 3. The description does not add any parameter-specific meaning beyond what the schema already provides, and it does not compensate for any gaps since there are none. Thus a 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 'Send a one-off email through your connected email account', specifying the verb and resource. It also distinguishes itself from bulk sending by explicitly naming campaigns as the alternative, making sibling differentiation strong.

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 'For bulk sending, use campaigns instead', naming the alternative tool and defining the boundary between one-off and bulk scenarios. Context is clear and exclusions are 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?

No annotations are provided, so the description carries the full burden. It discloses that the tool 'returns setup completeness' and a 'readiness percentage and actionable recommendations,' which is helpful. However, it does not explicitly state that it is read-only or non-destructive, though 'health check' implies this. The description could add a note about no 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 three sentences long, front-loaded with the primary purpose, and every sentence adds value. The list of checked items is compact, and the usage guidance is integrated seamlessly.

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 tool with no output schema, the description is complete. It explains what the tool does, what it returns (readiness percentage and recommendations), and when to use it. No critical missing context is apparent.

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 covers them trivially. Per the rubric, a baseline of 4 is appropriate. The description does not need to add parameter details since there are none.

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: 'Run a full health check on the OutreachPilot workspace.' It lists the specific resources checked (email accounts, ICP config, knowledge base, folders, contacts, campaigns, credits) and the output (readiness percentage, recommendations). This distinguishes it from sibling CRUD tools like list_contacts or get_campaign.

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

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

The description explicitly says 'Use this FIRST when starting a new conversation to understand what's configured and what needs setup.' This provides clear context for when to use the tool. It does not name specific alternatives or when-not-to-use conditions, but the 'first' guidance is sufficient for a health check 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?

With no annotations provided, the description must disclose behavioral details. It mentions auto-creating contacts and requiring an active campaign, but it omits the critical `confirmed` flag requirement, the idempotency behavior, and any side effects or error conditions. This is a significant transparency gap for a mutating operation.

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 only two sentences, front-loaded with the primary action, and contains no redundant filler. Every phrase 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 tool with 9 parameters, no output schema, and no annotations, the description is incomplete. It fails to mention the `confirmed` flag requirement, the `idempotency_key` duplicate-prevention feature, and the optional `linkedin_url` auto-create path. These are important for an agent to invoke the tool safely and 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 description adds meaning to the parameters by explaining that `contact_id` and the contact fields are alternative ways to identify or create a contact, and that `campaign_id` must reference an active campaign. This adds value beyond the schema's field-level descriptions, though it does not cover every parameter (e.g., `confirmed`, `idempotency_key`).

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 starts with a specific verb-resource pair ('Enroll a contact into an active campaign') and clearly distinguishes the tool's purpose from siblings like list_campaigns or get_campaign_status. It also explains the two enrollment modes (existing contact vs auto-create), 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 context on when to use the tool (enrolling a contact into an active campaign) and explains the two input modes, but it does not explicitly name alternative tools or state when not to use it. The 'campaign must be active' condition adds usage constraint.

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

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

No annotations are provided, so the description must disclose behavioral traits, but it only restates the purpose and fields. It does not mention any side effects, whether confirmation is required, or how the update interacts with existing campaigns. The 'confirmed' parameter is in the schema, but the description itself lacks 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 wasted words. It communicates the core action and the key exclusion in an efficient manner.

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

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

Given the complexity (7 params, nested objects, no annotations, no output schema), the description provides the necessary pointer to the alternative tool but omits broader context such as whether the update is reversible, the need for confirmation, or idempotency implications. However, the rich schema descriptions cover parameter details, keeping the description minimally viable but not fully complete.

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

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

Schema coverage is 100%, so the baseline is 3. The description adds no extra meaning beyond listing field names; it does not elaborate on parameter nuances, dependencies, or the significance of confirmed/idempotency_key beyond what the schema already states.

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 'update' and the resource 'campaign', and lists the specific fields that can be modified (name, config, steps, type). It also explicitly differentiates from the sibling tool update_campaign_status by redirecting status changes to that 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 an explicit alternative for status changes: 'For status changes (pause/resume/activate), use update_campaign_status instead.' This clearly indicates when not to use this tool and directs to the appropriate sibling.

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

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

With no annotations, the description carries the full burden. It lists state transitions but omits critical behavioral details: the 'confirmed' flag required for certain statuses, the idempotency key for retries, and any side effects or reversibility. This leaves the agent unaware of constraints.

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, terse sentence with zero wasted words. It is front-loaded with the key actions.

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 four parameters, no output schema, and no annotations, this description is under-specified. It fails to mention the confirmation requirement or idempotency behavior, which are essential for correct invocation and safe retries. The agent is left guessing about side effects.

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

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

Schema description coverage is 100%, so the baseline is 3. The description adds no additional parameter meaning beyond the schema. It does not clarify how status values map to actions or the confirmed requirement.

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 tool's action ('Pause, resume, activate, or archive') on a specific resource ('a campaign'). This distinguishes it from sibling tools like update_campaign, which likely handles other campaign settings.

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 this tool is for changing campaign status, but it does not explicitly contrast it with alternative tools (e.g., update_campaign) or state when not to use it. No exclusion or alternative guidance is provided.

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

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

No annotations are provided, so the description carries full burden. It discloses that the operation is an update (mutation), but it omits critical behavioral details such as the requirement for 'confirmed' to be true for the update to succeed, and it doesn't mention idempotency behavior or what happens if 'confirmed' is false. This is a significant transparency gap for a write operation.

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 extremely concise, using only two short sentences with no fluff. However, the second sentence about company_id is somewhat redundant given the schema, and the space could have been used to add the crucial 'confirmed' gate, making it efficient but not optimal in content utilization.

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 8 parameters, no output schema, and no annotations, the description is a bare minimum. It fails to mention essential contextual details like the confirmation flag requirement, the merge behavior for 'context', or any side effects. This leaves the agent without critical information needed for correct invocation, especially for a mutation 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 coverage is 100%, so all 8 parameters have descriptions in the schema. The description adds only 'You must provide the company_id,' which merely restates the required parameter and does not add meaning beyond the schema. It does not highlight the 'confirmed' parameter's role or the 'idempotency_key' behavior, but the schema already documents these.

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 action ('Update an existing company's fields') with a specific verb and resource, and 'existing' distinguishes it from create/delete operations. However, it does not explicitly name alternative sibling tools or elaborate on scope beyond 'fields'.

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: use this tool when you need to update an existing company's fields. There is no explicit guidance on when to use it versus alternatives like create_company or delete_company, nor any mention of prerequisites like the 'confirmed' flag being required for the update to take effect.

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

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

With no annotations, the description must disclose behavioral side effects, but it only states the update action and prerequisite. It does not mention that updating tags replaces the entire list, the idempotency key behavior, or any mutation risks. This lacks transparency for a write operation.

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 primary purpose and a key prerequisite. No fluff, 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 tool with 11 parameters, no annotations, and no output schema, this description is incomplete. It does not mention partial update semantics, tag replacement, confirmation requirements, idempotency, or return values, leaving critical behavioral and usage 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?

Schema coverage is 45%, so the description must compensate. It only elaborates on contact_id, telling users to provide it from search_contacts, but does not explain the other 10 parameters (e.g., tags replacement, confirmed requirement). The description adds minimal 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 'Update an existing contact's fields' with a specific verb and resource, distinguishing it from sibling tools like create_contact, delete_contact, and get_contact. This is an exact, non-tautological 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?

It provides clear usage context by requiring contact_id and explicitly recommends using search_contacts to find it. This is actionable guidance, though it does not explicitly list exclusions or alternative tools, it is sufficient for the resource.

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