Saber

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

The description explains the tool estimates count and cost, implying a non-destructive, read-like operation. However, annotations set readOnlyHint to false, which contradicts the preview nature, and the description does not clarify side effects or credit consumption behavior.

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

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

A single, well-structured sentence that presents the core functionality and output 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?

The description covers the two main outputs (count and credits) despite lacking an output schema. It is complete enough for a preview tool, though it could briefly mention the return type.

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 detailed descriptions for all filter fields. The description only mentions 'list filter' generically, but the schema already provides sufficient parameter 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 estimates both the count of matching companies and the credit cost of the list operation. This distinguishes it from siblings like company_lists-list or company_lists-export.

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

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

No guidance on when to use this tool versus other list-related tools (e.g., company_lists-search, company_lists-get_companies). The description does not indicate it is a preview before executing the actual list.

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

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

Annotations already indicate this is a mutating (readOnlyHint=false), non-idempotent, non-destructive operation. The description adds no behavioral details beyond the annotations, such as handling of duplicate names or side effects.

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

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

The description is a single sentence that efficiently conveys the core action and purpose without unnecessary words. It is front-loaded with the verb and resource.

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 basic purpose but does not address the return value (no output schema), which is relevant for an agent. Given the complexity of the input schema, the description relies on the schema's own documentation, which 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 detailed descriptions for all parameters (e.g., name max length, filter sub-properties). The description adds no additional parameter-level information, so baseline score of 3 is appropriate.

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

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

The description clearly states the verb 'Save' and the resource 'company filter as a reusable list', and distinguishes from sibling tools (e.g., get, list, update) by focusing on creation. The use cases (review, signals, scoring, export, CRM workflows) add specificity.

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 lists use cases but does not explicitly state when to use this tool versus alternatives (e.g., company_lists-update for modifications, company_lists-search for finding existing lists). No exclusion criteria or prerequisites are mentioned.

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

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

Adds context beyond annotations (removes segment boundary), but does not detail permanence, behavior on non-existent lists, or effects on associated data. Annotations already indicate destructiveness.

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

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

Single sentence, no wasted words, front-loaded key action and secondary effect.

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?

Sufficient for a simple delete tool with full schema coverage and annotations; could mention idempotency or error handling but not required.

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 the single listId parameter, and the description does not add any further meaning beyond the schema description.

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 ('Delete') and the resource ('saved company list'), and distinguishes it by noting the additional effect of removing its reusable segment boundary.

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

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

No guidance on when to use this tool versus siblings like contact_lists-delete or other delete tools; no prerequisites or exclusions 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?

The description lacks details on side effects, auth requirements, or rate limits. The readOnlyHint=false annotation conflicts with the export semantics, as export is typically a read-only operation. The description does not clarify this discrepancy.

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

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

The description is a single, front-loaded sentence that is concise and includes all key elements. No unnecessary words.

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

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

The description does not explain the output format details (e.g., how CSV is returned), error handling for invalid fields or large lists, or any limitations. Given the lack of output schema, more context would be beneficial.

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

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

The schema already provides detailed descriptions for all parameters (100% coverage). The description adds context about 'firmographic and signal columns' but does not add significant 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 clearly states the action (export), resource (saved company list), format (CSV), and optional inclusion of columns. It distinguishes from sibling tools like 'get' and 'get_companies' by focusing on export.

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

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

The description does not provide guidance on when to use this tool versus alternatives, such as when to use 'company_lists-get_companies' for programmatic access instead of export. No exclusions or prerequisites are mentioned.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false, idempotentHint=true, and openWorldHint=true, so the tool's safety profile is clear. The description adds specific behavioral context by noting it returns 'filter and current company count', which is not disclosed by annotations alone.

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, short, and direct sentence. It front-loads the purpose ('Retrieve company list metadata') and includes the key outputs without any unnecessary words 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 retrieval tool with strong annotations and a fully described schema, the description is nearly complete. It specifies what is retrieved (metadata with filter and count). It lacks details about return format or error handling, but these are not critical for such a straightforward operation.

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

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

The only parameter, listId, is already well-described in the schema ('The unique identifier of the company list') with 100% coverage. The description does not add any additional meaning or constraints beyond the schema, so it meets the baseline expectation.

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 company list metadata, specifying 'filter and current company count' as outputs. It uses the verb 'retrieve' and clearly identifies the resource, distinguishing it from sibling tools like get_companies (which retrieves companies) and list (which lists all lists).

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

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

The description does not explicitly state when to use this tool vs. alternatives. It implies it's for metadata retrieval, but lacks explicit guidance on when not to use it (e.g., when you need the actual companies in the list). No alternative tools are mentioned.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds that it 'page through companies', which is consistent with a read operation. It does not contradict annotations but adds minimal additional behavioral context beyond the annotations.

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

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

The description is a single sentence of 10 words, front-loaded with the action verb. Every word is necessary and contributes to understanding the tool's purpose.

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

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

Given the good annotations and fully described schema, the description covers the essential purpose but does not explain return format, pagination behavior, or error conditions. It is adequate but could be more complete for an AI agent.

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

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

Input schema coverage is 100%, with clear descriptions for all three parameters. The tool description does not add any additional meaning beyond what the schema already provides, meeting the baseline expectation.

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 'Page through' and identifies the resource as 'companies that match a saved company list filter'. This clearly distinguishes it from sibling tools like company_lists-get (which retrieves list metadata) and company_lists-search (which searches across lists).

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 saved company list and want to iterate over its companies, but it does not explicitly state when to use this tool versus alternatives like contact_lists-get_contacts or company_lists-search. No exclusions or when-not-to-use guidance is provided.

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

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

Annotations indicate the tool is not read-only and not idempotent, but the description adds no further behavioral context such as duplicate handling, overwrite behavior, rate limits, or authentication requirements. For a tool with side effects (importing data), this lack of detail is a significant gap.

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

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

The description is a single, front-loaded sentence with no wasted words. Every part contributes to understanding the tool's core purpose.

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

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

Given the tool's complexity (nested input, external data source, no output schema), the description is insufficient. It omits details about error handling, import limitations, or the nature of the operation (e.g., incremental vs. full import), leaving significant uncertainty for the agent.

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

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

Schema coverage is 100%, so the baseline is 3. The description adds context by naming the destination ('saved Saber company list'), but it does not meaningfully elaborate on parameter details beyond what the schema already provides (e.g., the 'name' parameter is explained as 'human-readable name' in the schema). The additional value is marginal.

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

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

The description clearly specifies the action (import), resource (companies), source (HubSpot list/view/segment), and destination (saved Saber company list). It distinctly differentiates from sibling tools like company_lists-create (which creates a new list without external data) and company_lists-export (which exports data).

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

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

The description states when to use the tool (importing from HubSpot), but it does not explicitly mention when not to use it or provide alternative tools. While the context is clear for a knowledgeable user, it lacks explicit exclusions or comparisons to sibling tools.

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

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

Annotations already declare readOnlyHint, idempotentHint, openWorldHint, and destructiveHint false. The description adds 'with pagination', which indicates pagination behavior beyond annotations. However, it omits details like ordering or response structure.

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 with no unnecessary words. It is appropriately sized for a simple list operation.

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

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

The tool has no output schema, so the description should hint at return values (e.g., array of list objects). It does not. Also missing details on sorting or default ordering, which are important for pagination.

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

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

Input schema has 100% description coverage for both parameters (limit, offset). The description adds no additional meaning beyond 'with pagination', so baseline of 3 is appropriate.

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

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

The description clearly states the tool lists saved company lists with pagination. It distinguishes this tool from siblings like company_lists-get (single list) and company_lists-search (filtered listing), though it does not explicitly differentiate from search.

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 (e.g., company_lists-search for filtered results). It does not mention excluded cases or prerequisites.

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

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

Annotations already indicate non-destructive (destructiveHint=false) and not read-only (readOnlyHint=false). The description adds the preview limit of 50 companies, which is helpful but does not disclose other behavioral traits like side effects or rate limits. No contradiction with annotations.

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

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

A single sentence of 16 words that front-loads the action and outcome. Every word is necessary; no redundancy. Extremely concise.

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

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

Given the complexity of the filter object and lack of output schema, the description adequately conveys the purpose and result (preview up to 50 companies). It could be slightly more complete by hinting at the returned fields, but it is sufficient for an AI agent.

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

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

Schema coverage is 100% with thorough descriptions for all parameters. The description adds no additional meaning beyond the schema, so baseline score of 3 is appropriate.

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

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

The description clearly states the tool previews up to 50 companies matching a filter, using specific verb 'preview' and resource 'companies'. It distinguishes from sibling tools like company_lists-create by indicating this is a preliminary step before creating a list.

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

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

The description implies use for previewing before list creation but does not explicitly state when not to use or compare to alternatives like company_lists-get_companies. No exclusions or conditions provided.

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

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

Annotations indicate idempotentHint=true and destructiveHint=false, and the description adds that the tool refreshes cached matching companies after update, providing behavioral context beyond the annotations.

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

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

The description is a single sentence that front-loads the verb and resource, contains no fluff, and is under 20 words.

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

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

Given the complex nested filter parameter and no output schema, the description adequately covers the core action. Mentioning cache refresh adds completeness, though a note about return values would improve 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?

Schema description coverage is 100%, so the schema already documents parameter details. The description adds no new parameter-level information beyond stating that name or filter can be updated, which aligns with the required fields.

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 'company list', specifying that it can update the name or filter. It also mentions the side effect of refreshing cached companies, distinguishing it from sibling tools like create, delete, or get.

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?

Implicitly, the description indicates usage for modifying list properties and refreshing matches. While it lacks explicit when-to-use or when-not-to-use guidance, the sibling tool names (e.g., company_lists-create, company_lists-delete) provide context, and the action is clear.

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

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

The description discloses the non-blocking behavior (immediate return with polling or webhook), which goes beyond annotations. It does not contradict annotations and adds value by explaining the async workflow.

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 of 20 words, concise and front-loaded with the core action. No unnecessary information.

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

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

The description captures the core behavior and async pattern, implicitly referencing the signal ID. Given the rich schema and annotations, it is largely complete. Minor omission: does not explicitly state the return value format.

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

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

The input schema has 100% description coverage, so the schema itself documents all parameters. The tool description does not add further parameter meaning beyond the schema, resulting in a baseline score 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 clearly states it creates a company research signal and explains the asynchronous nature (return immediately, then poll or webhook). It effectively distinguishes from sibling tools like get and create_batch.

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

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

The description implies usage for single signal creation but does not provide explicit guidance on when to use this tool over alternatives like batch creation or when to prefer webhook versus polling. No exclusions or alternatives are mentioned.

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

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

Annotations indicate it's not read-only, not destructive, not idempotent, and open world. The description adds 'Create many company signals' but does not elaborate on side effects, async behavior, or rate limits beyond what the schema already covers in the 'async' parameter.

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

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

The description is a single efficient sentence that directly states the purpose and a usage hint. However, it could benefit from more structure to help the agent parse different usage modes.

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 of the tool (nested objects, async option, Cartesian product logic), the description is too minimal. It does not explain the return format, async behavior, or performance limits, 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?

Schema description coverage is 100%, so the schema already documents all parameters. The description repeats the high-level concept of 'domains, questions, or templates' without adding new semantic meaning beyond what the schema provides.

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 many company signals across domains, questions, or templates, distinguishing it from the singular sibling 'company_signals-create'. The verb 'Create' and resource 'many company signals' are specific.

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 suggests using templates for larger standardized batches, implying a use case, but does not explicitly state when to use this tool versus the singular create tool or other alternatives. No when-not or exclusions 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?

Annotations already declare readOnlyHint=true, idempotentHint=true, and no destruction. The description adds that the tool returns the current status and AI-generated answer only after completion, which is valuable behavioral context beyond the annotations.

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

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

The description is a single, front-loaded sentence with no wasted words. It efficiently communicates the tool's purpose and condition.

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 one well-documented parameter, rich annotations, and no output schema, the description is nearly complete. It specifies what is returned (status and answer) but does not detail the answer structure. This is acceptable for a simple retrieval 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% with a clear description for signalId (UUID). The tool description does not add further parameter meaning beyond what the schema already provides, so a baseline score of 3 is appropriate.

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

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

The description clearly states the tool retrieves the current status and AI-generated answer for a company signal upon completion. The verb 'retrieve' and resource 'company signal' are specific, and it distinguishes from sibling tools like company_signals-create (creation) and company_signals-list (listing multiple signals).

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

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

The description implies usage when a signal has completed and you need its status and answer. It does not explicitly state when not to use or mention alternatives, but the context is clear given sibling tools and the single parameter signalId.

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

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

Annotations already declare readOnlyHint and idempotentHint; description adds no further behavioral details like pagination behavior or output format.

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

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

Single sentence, front-loaded, no 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?

Lacks details on pagination, sorting, output structure; minimal for a listing tool with 8 optional parameters and 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%, so the description adds minimal value beyond listing filter fields; no additional semantic context beyond schema.

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

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

The description clearly states the action (list) and resource (company signal runs), and lists the optional filters, distinguishing it from siblings like get (single) and create.

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

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

No guidance on when to use this tool versus alternatives; no mention of prerequisites or 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?

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false. Description adds no behavioral details beyond listing with filters, which does not contradict annotations but also adds no extra value.

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

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

Single sentence that is front-loaded with action and resource, followed by qualifiers. Zero unnecessary words.

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

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

Given the 8 parameters, clear schema descriptions, and annotations (read-only, idempotent), the description is adequate for a list tool. However, lacking an output schema, the description could hint at the structure of execution logs.

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

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

Input schema has 100% description coverage for all 8 parameters. The tool description does not add any additional meaning or context beyond the schema descriptions.

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

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

Clearly states the verb 'List', the resource 'company signal executions', and the qualifier 'produced by a specific signal subscription'. Distinguishes from sibling list tools like company_signals-list (all signals) and signal_subscriptions-list (subscriptions themselves).

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?

Implies usage by requiring subscriptionId, but no explicit guidance on when to use this vs. other list tools (e.g., company_signals-list) or alternatives. Lacks when-not-to-use context.

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

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

Annotations already declare the operation as read-only, idempotent, and non-destructive. The description adds minimal value by specifying that 'connection status' is included in the response, but it does not disclose pagination behavior, rate limits, or what constitutes a connector's 'status'.

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 a single, efficient sentence that front-loads the action and scope without filler words or redundant restatement of the tool name.

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

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

Given the tool's low complexity (no parameters, simple read operation) and rich annotations covering safety and idempotency, the description provides adequate context for invocation. It appropriately omits output schema details since none is provided, though mentioning pagination would have strengthened 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?

With zero parameters in the input schema, the baseline score applies. The description does not need to compensate for missing schema documentation, as there are no parameters requiring semantic explanation.

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 provides a specific verb ('List') and resource ('connectors and their connection status'), clearly distinguishing it from siblings like 'company_lists-list' or 'contact_lists-list' which handle different resources. It narrowly misses a 5 because it assumes domain knowledge of what 'connectors' refers to without contextualizing it.

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 offers no guidance on when to use this tool versus alternatives, nor does it mention prerequisites or filtering limitations. While there are no direct sibling alternatives for 'connectors', the description fails to indicate appropriate usage contexts (e.g., polling vs. initial setup).

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

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

Annotations indicate mutation (readOnlyHint=false) and potential broader effects (openWorldHint=true). The description adds that it runs a LinkedIn Sales Navigator search (which may incur costs or rate limits) and stores a snapshot (implying data freshness considerations). This adds valuable context beyond annotations.

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

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

The description is a single sentence that is concise and front-loaded, covering the main action without redundant words. Every part earns its place.

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

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

Given the complexity (nested parameters, no output schema), the description explains the overall process but lacks details about the returned metadata structure, limitations (max results, timeouts), or how the snapshot is stored. It is adequate but could be more complete.

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

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

Schema description coverage is 100%, so baseline is 3. The description explains that the filters parameter is used for a search, providing context but not adding detailed semantics beyond what the schema already provides (e.g., examples and descriptions for each filter field).

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 runs a LinkedIn Sales Navigator search, stores a point-in-time contact snapshot, and returns contact list metadata. This distinguishes it from sibling tools like contact_lists-get or contact_lists-update by specifying the creation action and the search-based population.

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

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

The description implies usage for creating a contact list via search but does not explicitly state when to use this tool over alternatives like company_lists-create or contact_lists-update. No exclusions or prerequisites are mentioned.

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

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

Annotations already indicate destructiveHint=true and idempotentHint=true. The description adds that deletion is permanent and also removes stored contact snapshots, which is beyond the annotations. However, it does not disclose behavior if the list does not exist or authentication requirements.

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

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

The description is a single, clear sentence with no unnecessary words or repetition. It is appropriately sized and front-loaded.

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

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

Given the tool's simplicity (one required param, no output schema, no nested objects), the description covers the core action and side effects (deleting snapshots). It might be improved by noting irreversibility, but the destructive annotation already implies this. Overall, it is sufficient.

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 listId described. The description does not add any meaning beyond what the schema provides (the unique identifier of the contact list). Baseline score of 3 is appropriate.

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

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

The description clearly states the tool's purpose: 'Permanently delete a contact list and its stored contact snapshots.' It uses a specific verb (delete) and resource (contact list), and distinguishes from sibling tools like create, update, get, list.

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

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

The description provides no guidance on when to use this tool vs alternatives. It does not mention prerequisites (e.g., ownership, existence of the list) or situations where deletion might be inappropriate. Sibling tools include various contact list operations, but no comparative context is given.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false. The description adds that it retrieves 'metadata and the stored contact count,' which goes beyond the annotations. No contradictions.

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

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

Single sentence, no wasted words. Front-loaded with the action and result. Every word earns its place.

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

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

Given the simple get operation and rich annotations, the description is fairly complete. It explains what is returned. However, without an output schema, the agent lacks details on the format of metadata, but that's beyond the description's responsibility.

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 the listId parameter fully described. The description does not add meaning beyond what the schema provides; it simply repeats the concept of an identifier. Baseline of 3 is appropriate.

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

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

The description clearly states the tool retrieves contact list metadata and stored contact count. It uses specific verbs and distinguishes from siblings like contact_lists-get_contacts (which retrieves contacts) and contact_lists-list (which lists all lists).

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

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

No explicit guidance on when to use this tool versus alternatives (e.g., when you need contacts vs metadata). The usage is implied from the simple retrieval nature, but no when-not-to-use 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?

Annotations already indicate read-only, idempotent, non-destructive behavior. The description adds value by specifying that no new Sales Navigator request is made, which is a key behavioral trait beyond annotations.

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

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

A single sentence that is efficient and front-loaded with the action. Every word contributes to understanding 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 simple pagination tool, the description covers the core purpose and distinguishing behavior. No output schema exists, but the annotations and parameter descriptions provide sufficient context. Slightly incomplete on return details, but adequate given the annotations.

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

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

100% schema description coverage means the input schema already documents all parameters. The description does not add new meaning beyond the schema, resulting in a baseline score 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 clearly states the verb 'Page through', the resource 'contacts stored in a saved list', and the distinguishing feature 'without making a new Sales Navigator request', setting it apart from sibling tools like contact_lists-get and contact_lists-list.

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

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

The description implies usage for retrieving contacts without a new request but does not explicitly state when to use it vs. alternatives, nor does it provide exclusions or when-not conditions.

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

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

Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint, so the safety profile is covered. Description adds pagination context but no additional behavioral traits beyond that.

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

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

Single sentence with no wasted words. Front-loads the action and resource, and includes pagination detail efficiently.

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

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

Adequate for a simple list operation with good annotations, but lacks description of return format (e.g., array of lists) since no output schema exists. Could be more 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 clear parameter descriptions for limit and offset. The description mentions pagination but adds no meaning beyond what the schema already provides, so 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?

Description clearly states verb 'list' and resource 'saved contact lists', and mentions 'pagination'. It distinguishes from sibling 'contact_lists-get' which retrieves a single list.

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

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

No explicit guidance on when to use this tool vs alternatives like 'contact_lists-get'. Usage is implied but not stated, and no when-not or exclusion criteria 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?

Annotations indicate non-read-only, idempotent, non-destructive behavior. The description adds value by clarifying that the stored contact snapshot remains unchanged, which goes beyond the annotations.

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

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

A single, clear sentence that front-loads the action and key constraint with no unnecessary words.

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

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

The description lacks information about the return value or response format (no output schema). Given the simplicity of the tool, some guidance on side effects or response type 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?

The input schema has 100% coverage, but the description adds context that the operation is a rename and that contacts are unaffected, providing extra semantic value beyond the schema descriptions.

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

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

The description explicitly states the verb (rename), resource (saved contact list), and a key constraint (without changing stored contacts). It distinguishes this tool from siblings that delete, create, or export lists.

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

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

The description implies usage for renaming a list without altering contacts, but it does not explicitly state when to use this tool over alternatives (e.g., company_lists-update) or exclude scenarios like bulk updates.

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

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

Annotations indicate readOnlyHint=false, openWorldHint=true. Description adds that research is asynchronous and requires polling, which is valuable behavioral context beyond annotations. No contradictions.

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

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

Single sentence, no redundancy, front-loads key action and follow-up step. Highly concise.

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

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

With high parameter count and no output schema, the description covers the essential workflow: start and poll. Could mention that the research ID is returned, but it's implied by 'poll the research ID'.

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 detailed descriptions; baseline is 3. Description adds minimal extra semantic meaning (e.g., 'using LinkedIn and other sources') but not enough to elevate score.

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

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

Clearly states the action ('Start asynchronous AI research'), the resource ('for a contact'), and sources ('LinkedIn and other sources'). Distinct from siblings like 'contacts-get_research' which polls results.

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

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

Explicitly says to 'poll the research ID for results', indicating async usage pattern. Context is clear, but does not explicitly mention when not to use this tool or name specific alternatives.

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

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

The description discloses the async behavior, immediate return, and result retrieval methods (polling ID or webhook). Annotations confirm mutation (readOnlyHint=false) and non-destructive nature. The description adds value beyond annotations by detailing the workflow.

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

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

The description is a single concise sentence that front-loads the main action and key behavior. It is efficient, though could be slightly restructured for clarity (e.g., separating the creation from retrieval steps).

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 captures the essential async workflow but omits details about the return value (e.g., the signal ID structure) and fails to explain how to poll or set up webhooks. Given no output schema and many parameters, it is moderately complete but lacks guidance on interpreting results.

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 minimal parameter-specific information, mainly referencing webhookUrl through context. The async behavior is hinted but not tied to specific parameters.

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

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

The description clearly states the tool creates a contact research signal and explains the asynchronous behavior (return immediately, then poll or webhook). It distinguishes from synchronous research tools like `contacts-create_research` by implication, but does not explicitly differentiate from `company_signals-create`.

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 async results are needed, mentioning polling and webhooks. However, it lacks explicit guidance on when to use this tool versus alternatives (e.g., synchronous research or batch creation) and 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?

Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint. The description adds the timing condition (when completed) and clarifies that it retrieves both status and insights, complementing the annotations without contradiction.

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

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

The description is a single sentence that is front-loaded and contains no extraneous information. 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?

While the tool has no output schema, the description mentions 'status and AI-generated insights', which gives some idea of the return. However, it lacks details about the output structure, which is a gap for a read operation.

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

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

The single parameter 'id' is fully described in the schema (100% coverage), so the description adds no additional meaning beyond what the schema provides. Baseline 3 is appropriate.

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

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

The description clearly states the verb (retrieve) and resource (contact research job status and insights) and specifies the condition (when completed). It distinguishes from siblings like contacts-create_research (which creates the job) and contacts-get_signal (which gets a signal).

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 after a research job has completed, which provides clear context. However, it does not explicitly state when not to use or list alternatives, though the context is sufficient for typical use.

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

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

Annotations already declare readOnlyHint, idempotentHint, and non-destructive nature. The description adds that the tool returns status and AI-generated answer, providing context beyond the annotations.

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

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

The description is a single concise sentence (15 words) that front-loads the purpose without any unnecessary 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 read operation with one parameter and no output schema, the description sufficiently explains what the tool returns (status and answer) and when to use it (when completed).

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 the single parameter signalId with full description and pattern. The description adds no additional parameter information, so baseline score of 3 is appropriate.

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

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

The description clearly states the verb 'Retrieve' and the resource 'current status and AI-generated answer for a contact signal', distinguishing it from sibling tools like contacts-create_signal and contacts-list_signals.

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 specifies the condition 'when it has completed', indicating when to use the tool, but does not provide explicit when-not or alternative tools.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the description adds only filter and pagination context. No additional behavioral details (e.g., return format, rate limits) are provided, but the annotations cover the main 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?

Single sentence, no fluff, perfectly concise. All information is front-loaded and directly relevant.

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

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

Given no output schema, the description could mention what the list returns (e.g., signal run objects). The description is adequate for a simple read operation, but lacks details on response structure or pagination behavior beyond parameters.

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%, with each parameter already described. The description mentions 'optional filters for profile URL and pagination,' aligning with the schema but adding no new meaning beyond it.

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

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

The description uses a specific verb (List) and resource (contact signal runs) and mentions optional filters and pagination, clearly distinguishing it from sibling tools like contact_lists-list or market_signals-list_signals.

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

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

No guidance on when to use this tool versus alternatives such as market_signals-list_signals or contact_lists-list. The description only states capabilities, leaving the agent to infer 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?

The description adds no behavioral beyond what annotations already provide, and there is a potential contradiction: 'Search' implies a read-only operation, but readOnlyHint=false suggests possible side effects. No mention of pagination, rate limits, or connection requirements.

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

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

The description is a single sentence that is front-loaded with the action and key filters. It is concise without being vague, but could benefit from slightly more 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?

Given the complexity (11 parameters, no output schema), the description does not mention return format, pagination details (though present in schema), or how the Sales Navigator connection is used. It is adequate but has 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%, and the description lists filter categories (company, name, job title, etc.) that map to parameters, but adds no new meaning beyond summarizing the schema. Baseline 3 is appropriate.

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

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

The description clearly states 'Search for contacts' and lists multiple specific search dimensions (company, name, job title, etc.), making the purpose highly specific and distinct from sibling tools like company_lists-search or contacts-create_research.

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 mentions using the API key owner's Sales Navigator connection, which provides some context, but it does not explicitly state when to use this tool versus alternatives, nor does it provide exclusions or prerequisites.

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

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

Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint=false. Description adds no extra behavioral context beyond stating the 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?

Single sentence, clear and front-loaded with no extraneous 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?

Sufficient for a simple read-only check tool with no parameters and no output schema. Tells what is returned (credits left, organization, billing period).

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

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

No parameters, so baseline is 4. Description adds no parameter info, but none needed.

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

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

Description clearly states verb 'check', resource 'Saber API credits', and scope 'your organization has left in the current billing period'. It distinguishes from sibling tools, none of which deal with credits balance.

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

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

No explicit when-to-use or alternatives, but context makes it clear as the sole credit-related tool among siblings. Minimal guidance.

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

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

The description does not disclose behavioral traits beyond what annotations provide. Annotations indicate non-read-only and non-destructive, but the description adds no context on side effects, authentication requirements, or rate limits.

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

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

Single sentence, front-loaded with the verb and purpose, 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?

No output schema is present, and the description does not explain what is returned (e.g., email address, confidence score) or handle error cases beyond schema-level rejections. The description is incomplete for a lookup 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 input schema provides detailed descriptions for both parameters (100% coverage), so the tool description adds minimal extra meaning beyond what is already documented in the schema.

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

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

The description clearly states the action ('Find'), the resource ('verified email address'), and the context ('for a contact at a domain'). It is specific and distinct from sibling tools, which do not focus on email lookup.

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

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

No guidance on when to use this tool versus alternatives. The description implies the need for a full name and domain but does not mention when not to use it or provide alternative tool names for related tasks.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering safety. The description adds a concrete example but does not disclose additional behaviors like rate limits or authentication. With good annotation coverage, a score of 3 is appropriate.

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

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

The description is a single, well-structured sentence that front-loads the verb and resource. No unnecessary words.

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

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

The description does not explain the return value or format, despite lacking an output schema. For a simple read tool with good schema and annotations, this is adequate but could be more complete.

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

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

Schema description coverage is 100%, so the schema already documents both parameters. The description reiterates the schema's meaning without adding new details. Baseline 3 is correct.

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 'Retrieve' and the resource 'contact research', specifies the identifier type (external system ID) with an example (HubSpot contact ID), and includes the source name. This distinguishes it from sibling tools like 'contacts-get_research' which likely use internal IDs.

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

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

The description provides clear context for when to use this tool (when you have an external system ID and source name). However, it does not explicitly state when not to use it or mention alternatives like 'contacts-get_research' for internal ID lookups.

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

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

Annotations indicate readOnlyHint=false (mutation) and openWorldHint=true. The description confirms creation but fails to disclose side effects like activation of polling, cost implications, or that the subscription immediately becomes active. More behavioral context is needed beyond 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 a single, efficient sentence that front-loads the purpose. It avoids unnecessary words, though it could be slightly expanded to include usage guidance without harming conciseness.

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 of the tool (nested __requestBody object, multiple parameter types, no output schema), the description is insufficient. It omits what the response contains (e.g., subscription ID), activation timing, and the dependence on webhookUrl. A more complete description would aid correct invocation.

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

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

With 100% schema description coverage, the input schema already explains all parameters. The tool description adds no additional semantic value beyond listing signal types, which is redundant with the type enum description in the schema. Flat baseline of 3 is appropriate.

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

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

The description clearly states the tool creates a market signal subscription and lists the specific signal types it monitors (job posts, LinkedIn posts, fundraising, investments, IPOs). This distinguishes it from sibling tools like market_signals-delete_subscription or market_signals-list_subscriptions.

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 (e.g., signal_subscriptions-create or market_signals-update_subscription). It lacks prerequisites, use cases, or exclusions, leaving the agent to infer context from sibling names alone.

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

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

The description adds no behavioral context beyond what annotations provide. It fails to explain idempotency implications (safe to retry), what happens to historical signal data after deletion, or the irreversible nature of the operation despite destructiveHint being true.

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?

Extremely concise at five words with no redundancy. The action is front-loaded. However, the brevity comes at the cost of missing contextual guidance that would help an agent select this over similar tools.

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?

Adequate for a single-parameter deletion tool with good safety annotations, but incomplete given the rich sibling ecosystem. Lacks explanation of side effects (cascading deletions, webhook cleanup) and differentiation from pausing or other subscription deletion endpoints.

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

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

With 100% schema description coverage for the single subscriptionId parameter, the schema carries the full load. The description adds no supplementary context about where to obtain the UUID or validation edge cases, warranting the baseline score for high-coverage schemas.

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 clear verb ('Delete') and specific resource ('market signal subscription'), accurately reflecting the tool name prefix. However, it does not distinguish from similar deletion siblings like 'signal_subscriptions-delete' or explain the domain-specific meaning of 'market signal' vs other signal types.

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 provided on when to use delete versus the available 'pause' and 'resume' siblings, nor any mention of prerequisites (e.g., subscription status) or irreversibility warnings. The agent must infer usage purely from the verb.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint. The description adds nothing about error behavior (e.g., not-found scenarios), return value structure, or side effects beyond the annotations. With rich annotations provided, this minimal addition earns a low score.

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

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

Single efficient sentence front-loaded with action verb. No filler words or redundant phrases. Appropriate length 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?

Minimum viable for a simple retrieval tool with one parameter and rich annotations. However, lacking an output schema, the description omits what fields/properties the returned subscription contains and doesn't mention error cases (invalid UUID, subscription not found).

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 detailed UUID pattern and description. The description mentions 'by ID' but adds no semantic depth regarding the subscriptionId format or constraints beyond what the schema already documents. Baseline score appropriate for high schema coverage.

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

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

States clear verb (Get) and resource (market signal subscription) with scope (by ID). However, it fails to differentiate from sibling tool `signal_subscriptions-get`, which has an ambiguously similar name/purpose but exists in a different namespace.

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

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

Provides no guidance on when to use this single-item retrieval versus `market_signals-list_subscriptions`, nor when to prefer this over `signal_subscriptions-get`. No prerequisites or exclusions 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?

The annotations already declare read-only, idempotent, and non-destructive properties, so the description correctly avoids repeating safety characteristics. It adds minimal behavioral context beyond the annotations, merely stating signals are 'delivered by' a subscription without describing return format, chronological ordering, or pagination behavior. The description does not contradict the annotations.

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

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

The description is a single seven-word sentence with no redundant phrasing or tautology. It efficiently conveys the core operation but may be overly terse given the tool's place in a multi-step workflow requiring a subscription ID from a prior call. The information density is high, though additional context would improve utility without significantly sacrificing brevity.

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 comprehensive input schema (100% coverage) and detailed annotations, the description provides sufficient context for basic invocation. However, it lacks explanation of the output structure (which has no schema), the expected workflow sequence (dependency on subscription creation/listing), and the semantic nature of the signals returned. For a tool with three parameters and pagination capabilities, the description meets minimum viability but leaves gaps in domain context.

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

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

The input schema has 100% description coverage for all three parameters (subscriptionId, limit, offset), clearly documenting types, constraints, and purposes. The description does not add additional semantic context—such as explaining the pagination pattern or that subscriptionId must come from a prior `list_subscriptions` call—beyond what the schema already provides. Baseline score applies since the schema carries the full burden.

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 'List signals delivered by a market signal subscription' clearly identifies the verb (List) and resource (signals). It implicitly distinguishes from siblings like `market_signals-list_subscriptions` (which lists subscription configurations, not signal data) by specifying signals 'delivered by' a subscription. However, it does not explicitly clarify when to use this versus `company_signals-list` or `contacts-list_signals`.

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 select this tool over alternatives such as `market_signals-list_subscriptions` (for subscription metadata) or `company_signals-list` (for company-specific signals). It omits workflow prerequisites, such as needing to first obtain a subscription ID via `market_signals-list_subscriptions`, and mentions no exclusion criteria or error conditions.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint. The description adds the 'organization' scope constraint, but doesn't explain pagination behavior, soft-deletion semantics, or what constitutes a 'market signal' versus other signal types.

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

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

Single sentence of 9 words with no redundancy. Purpose is front-loaded and immediately clear.

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

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

Adequate for a simple list operation with good annotations and schema coverage, but incomplete due to missing differentiation from similar subscription-listing tools and lack of guidance on handling paginated results.

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 parameters are fully documented in the schema. The description mentions none of them, which is acceptable given the high schema coverage, meeting 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 clearly states the verb (List) and resource (market signal subscriptions) with organizational scope. However, it fails to distinguish from the sibling tool 'signal_subscriptions-list', leaving ambiguity about which subscription type to query.

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 provided on when to use this versus 'signal_subscriptions-list' or other market_signals tools. No mention of pagination strategy for large result sets or when to set includeDeleted=true.

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

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

While annotations indicate the operation is non-idempotent (idempotentHint: false) and non-destructive, the description adds no context about what happens on subsequent calls, what 'paused' state implies for data flow/billing, or the implications of openWorldHint.

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 brief (5 words) and front-loaded, but functions as a tautology restating the tool name. It wastes no words, yet fails to earn its place by adding actionable value beyond labeling.

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

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

Given the complex sibling landscape with overlapping functionality (e.g., 'subscription_actions-pause', 'market_signals-resume_subscription') and a mutation with non-idempotent behavior, the description is insufficient. It lacks explanation of side effects, return values, or state transitions.

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

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

With 100% schema description coverage, the parameter 'subscriptionId' is fully documented in the schema itself. The description adds no additional semantic information (e.g., format details, where to obtain the ID), meriting the baseline score.

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

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

The description states a clear verb ('Pause') and resource ('market signal subscription'), accurately reflecting the tool's function. However, it fails to distinguish from the similar sibling tool 'subscription_actions-pause', which could confuse tool selection.

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 like 'subscription_actions-pause' or 'signal_subscriptions-stop', nor does it mention prerequisites such as whether the subscription must be active to pause.

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

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

Annotations already indicate this is a non-read-only, non-idempotent mutation (readOnlyHint: false, idempotentHint: false). The description adds context that this is a state transition from paused to active, but does not elaborate on side effects, failure modes if the subscription isn't paused, or billing implications.

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

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

The single sentence is front-loaded with the action verb, contains zero redundancy, and is appropriately sized for a simple single-parameter state transition tool. No extraneous information is present.

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 low complexity (1 parameter, 100% schema coverage, clear annotations), the description adequately covers the tool's purpose. It could be improved by explicitly stating the paused-state requirement or referencing the pause sibling tool, but it is sufficient for correct invocation.

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

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

With 100% schema description coverage for the single 'subscriptionId' parameter, the schema fully documents the input requirements. The description does not add additional parameter semantics (e.g., where to find the ID), warranting the baseline score 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 the specific verb 'Resume' with the resource 'paused market signal subscription', clearly indicating this tool reactivates subscriptions. It effectively distinguishes from the sibling 'market_signals-pause_subscription' by specifying the target state (paused) and action (resume).

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 a precondition by stating 'paused' subscription, suggesting it should only be used on subscriptions in that state. However, it lacks explicit guidance on when not to use it (e.g., on active subscriptions) or explicit reference to the 'pause_subscription' sibling as the inverse operation.

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?

Adds 'immediate run' context not present in annotations, clarifying the action's effect. However, fails to explain implications of idempotentHint=false (multiple calls = multiple runs) or openWorldHint=true (external side effects), which are critical for an action tool.

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

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

Single sentence with strong verb-first structure and zero redundancy. Appropriately brief for a simple single-parameter tool, though slightly too terse given the complex sibling ecosystem and behavioral nuances.

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?

Lacks return value description (no output schema exists) and omits execution model details (sync/async, job status). Given the non-idempotent nature and similarity to other trigger tools, the description is insufficient for confident invocation.

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

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

Schema coverage is 100% with complete parameter description. The tool description doesn't add validation guidance, examples, or semantic constraints beyond what the schema already provides, meeting baseline expectations.

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?

Uses specific verb 'Trigger' and resource 'market signal subscription' to distinguish from CRUD siblings (create/delete/update). However, fails to differentiate from the similarly-named 'signal_subscriptions-trigger' tool, which could cause selection confusion.

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

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

Provides no guidance on when to use this versus 'signal_subscriptions-trigger' or 'subscription_actions-create'. Missing prerequisites (e.g., subscription state requirements) and excludes mention of idempotency implications.

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

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

Annotations already indicate the tool is not read-only, not destructive, and not idempotent. The description adds no additional behavioral context, such as that changing the interval restarts the polling schedule (which is only in the schema, not the description).

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 (one sentence) but at the cost of informativeness. It is nearly a tautology and does not earn its place by providing additional clarity or context.

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

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

Given the tool has no output schema and a complex nested parameter, the description should explain what happens after an update (e.g., response details, side effects). It fails to provide any contextual completeness beyond the bare minimum.

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

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

The input schema has 100% description coverage for all parameters, including nested fields. The description itself does not elaborate on parameters, so it adds no value beyond the schema, meeting the baseline expectation.

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 'Update a market signal subscription' clearly states the verb (Update) and resource (market signal subscription), but it does not differentiate from sibling tools like pause, resume, or trigger subscriptions. It is sufficient but not specific enough to distinguish the tool's unique 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 no guidance on when to use this tool versus alternatives, such as when to update vs. create or pause. There is no mention of prerequisites, effects, or exclusivity with other tools.

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

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

Annotations comprehensively cover safety (readOnly, non-destructive, idempotent), but the description adds no supplementary behavioral context such as caching policies, rate limits, or the structure/content of the returned profile.

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?

Extremely efficient at four words. Front-loaded with the action verb, zero redundancy, and appropriately sized for a no-parameter getter tool.

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

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

Adequate for tool selection given the simple read-only nature, but lacks description of return values (particularly since no output schema is provided) which would help the agent understand what data is available in the profile.

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

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

Input schema contains zero parameters, establishing a baseline score of 4. The description appropriately reflects the absence of required inputs.

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

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

The description clearly states the verb ('Get') and resource ('organisation profile'), distinguishing it from the sibling 'organisation-update'. However, it lacks specificity about what constitutes an 'organisation profile' (e.g., fields included).

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 provided on when to use this versus alternatives, or prerequisites for invocation. While it is implied to be the read counterpart to 'organisation-update', this relationship is not 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?

Annotations already indicate this is a write operation (readOnlyHint=false), not destructive (destructiveHint=false), idempotent, and open-world. The description adds no behavioral context beyond these annotations, so it is adequate but not enhanced.

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 with no fluff, front-loading the purpose. However, it is very brief and could incorporate more usage guidance without becoming verbose.

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

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

Given the nested object complexity (6 fields) and lack of output schema, the description is insufficient. It does not explain partial update behavior, success response, or error handling, leaving gaps for an AI agent.

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

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

Schema coverage is 100% with descriptions for all parameters. The description adds no additional meaning beyond what the schema provides, meeting the baseline but not exceeding it.

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 'Update your organisation profile' clearly states the verb (update) and resource (organisation profile). It distinguishes from siblings like organisation-get which is read-only. However, it does not specify that updates are partial, as the schema indicates all fields within the request body are optional.

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. There is no mention of prerequisites, conditions, or when not to use it. The presence of sibling tools like organisation-get suggests a distinction, but the description does not clarify.

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

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

Annotations indicate it's a write operation (readOnlyHint false) and not idempotent. The description should disclose side effects like whether assignments are additive or overwrite, or if partial failures occur. No behavioral details beyond 'assign' are given, leaving the agent uninformed about error handling or concurrency.

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

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

A single, front-loaded sentence contains all essential information. No redundant words or tangential details. The structure is optimal for quick comprehension.

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

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

Given the tool is a bulk mutation with no output schema, the description should clarify return format (e.g., success/failure per object, assignment IDs). It omits any mention of response data, potential errors, or prerequisites like profile existence. The description is incomplete for a complex operation that could have partial results.

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 the schema's own parameter descriptions (e.g., objectIds cap, profileId format). It does not clarify parameter relationships or provide examples. The description merely restates the tool's action without enriching parameter understanding.

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 'Assign a profile to many objects at once' clearly states the verb (assign), resource (profile and objects), and scope (many objects). The tool name includes 'bulk-create', distinguishing it from sibling 'scoring-assignment-create' that handles single assignments. This is 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 implies bulk assignments but provides no explicit when-to-use or when-not-to-use guidance. It does not mention alternatives like 'scoring-assignment-create' for single assignments or when to paginate. The schema's maxItems hint is the only contextual cue, but the description itself lacks usage direction.

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

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

Annotations indicate a non-readonly, open-world, non-idempotent mutation. The description adds no behavioral details beyond what annotations provide, such as whether it overwrites existing assignments, or what happens on duplicate assignment.

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

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

The description is a single concise sentence with no wasted words. It is front-loaded but could be slightly more informative without becoming verbose.

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

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

The tool has three parameters, a nested schema, and no output schema. The description fails to explain return values, side effects, or error behavior, leaving significant gaps for the agent to infer.

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 parameters with descriptions for objectId and objectType, and profileId has format/pattern constraints. The description does not add extra meaning, so baseline score of 3 is appropriate given 100% 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 'Assign a profile to a single object' clearly states the action (assign) and resource (profile to object). It distinguishes from the sibling scoring-assignment-bulk-create by implying single assignment. However, it could be more explicit about 'scoring profile' and 'company/contact' object types.

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 like scoring-assignment-bulk-create. The description does not specify prerequisites, error conditions, or context for use.

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

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

Annotations already indicate destructiveHint=true and idempotentHint=true. Description merely says 'Remove', aligning with annotations but adding no extra behavioral context (e.g., irreversibility, auth requirements).

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

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

Extremely concise single phrase, front-loaded. However, could include a bit more context without losing brevity.

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

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

For a simple delete tool with one parameter and no output schema, the description is minimally adequate but lacks mention of return behavior or side effects beyond the destructive nature.

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 provides full coverage for the single parameter (assignmentId) with format and pattern. Description adds no additional meaning 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?

Description clearly states the action 'Remove' and the resource 'profile assignment', distinguishing it from siblings like 'scoring-assignment-create' or 'scoring-assignment-list'.

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

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

No guidance on when to use this tool vs alternatives, such as when to delete vs update or list assignments. No prerequisites or when-not-to-use information.

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

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

Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint=false, covering safety. The description adds no new behavioral details (e.g., no mention of what 'assignments' are or any constraints), but does not contradict annotations.

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

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

The description is a single, concise sentence with no wasted words, front-loading the core action.

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

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

For a simple 2-parameter list tool with no output schema, the description is fairly complete given the annotations and naming context. It could optionally specify 'scoring profile assignments' but 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 clear descriptions for both parameters (objectId format and objectType enum). The description does not add additional meaning beyond the schema, meeting the baseline.

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

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

The description 'List profile assignments for an object' clearly states the verb (list) and the resource (profile assignments), distinguishing it from mutation siblings like scoring-assignment-create and scoring-assignment-delete.

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 such as scoring-profile-list or other list tools. The description lacks context on prerequisites or scenarios.

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

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

Annotations indicate a mutation (readOnlyHint=false), not idempotent, not destructive. The description adds no further behavioral detail such as side effects, async behavior, or length of computation. Contradictions: none.

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 short (three words), which is concise but at the expense of essential information. It is not front-loaded with key details like parameters.

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 nested parameters, no output schema, and mutation nature, the description is incomplete. It fails to explain what recomputation entails, synchronization, or return value.

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 clear descriptions for objectType and objectIds. The tool description adds no additional meaning beyond what the schema already provides.

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 'Trigger score recomputation' provides a clear verb and resource, but it is vague and does not distinguish from sibling tools like scoring-scores-get or scoring-profile-update. It lacks specificity about what type of scores are recomputed.

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

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

No guidance is given on when to use this tool, prerequisites, or alternatives. The description is entirely silent on 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?

Annotations already indicate that this is not read-only (readOnlyHint=false) and not destructive (destructiveHint=false). The description adds no behavioral context beyond annotations, such as side effects, authentication needs, or what happens upon creation.

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 very concise (4 words) and front-loaded. However, it could be slightly more informative without losing conciseness (e.g., adding 'with required profileType and name').

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 creation tool, the description is incomplete. It does not mention required fields, return values, or any implications. Given the presence of nested objects and no output schema, the description should provide more context.

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

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

Schema coverage is 100%, so the schema documents all parameters fully. The description does not add additional meaning beyond what the schema provides. 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 ('Create') and resource ('a scoring profile'), distinguishing it from sibling tools like scoring-profile-get, scoring-profile-list, etc. However, it lacks any additional context about what a scoring profile is or 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?

No guidance on when to use this tool versus alternatives (e.g., scoring-profile-update). The description does not mention prerequisites, constraints, or typical use cases.

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

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

Annotations already indicate destructiveHint=true and idempotentHint=true. The description adds no additional behavioral context (e.g., irreversibility, required permissions, or consequence of deleting a referenced profile).

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

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

One short sentence (4 words) with no wasted text, front-loading the action clearly.

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

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

For a simple delete with one parameter and clear annotations, the description is minimally adequate but lacks any behavioral context (e.g., irreversibility, impact on related data).

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

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

Input schema covers 100% of parameters with full description ('Scoring profile UUID'). Description adds no extra meaning, but schema is sufficient, giving a baseline score 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 'Delete a scoring profile' clearly states the action (Delete) and resource (scoring profile), distinguishing it from sibling tools like create, get, list, and update.

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

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

No guidance on when to use this tool versus alternatives, no prerequisites or conditions for deletion, and no mention of irreversible side effects.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false, idempotentHint=true, and openWorldHint=true. The description adds no additional behavioral context beyond what annotations provide, and there is no contradiction.

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 is concise but could be considered too terse; however, for a simple tool it is appropriate.

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

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

Given the tool's simplicity (one required parameter, no output schema, annotations covering behavior), the description is sufficient. It states the core function, though it does not mention return format or additional context.

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

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

Schema description coverage is 100%; the single parameter 'profileId' is described as 'Scoring profile UUID' in the schema. The tool description adds no extra 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 'Get a scoring profile' clearly states the action (get) and resource (scoring profile), distinguishing it from siblings like scoring-profile-list (list multiple) and scoring-profile-create (create).

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

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

No explicit guidance on when to use this tool versus alternatives like scoring-profile-list or scoring-profile-get other than the implied difference from the name and sibling context. Lacks explicit when/not instructions.

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

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

Annotations already indicate read-only, idempotent, non-destructive behavior. The description adds no new behavioral information beyond the fact that it lists profiles. It does not mention pagination, sorting, or any output characteristics, which would be helpful given the absence of an output 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 a single, concise sentence that directly states the tool's function. There are no wasted words, and the key action is front-loaded. Every word earns its place.

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

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

Given the tool's simplicity (no parameters, rich annotations), the description is nearly complete. It could optionally mention that the output is a list of scoring profiles, but the function is self-evident. The lack of an output schema is compensated by the tool's straightforward nature.

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 semantics. The input schema coverage is 100% (by virtue of being empty). Per guidelines, 0 parameters baseline is 4, and the description does not provide misleading or unnecessary information.

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 'List scoring profiles' uses a clear verb ('List') and a specific resource ('scoring profiles'). However, it does not explicitly differentiate itself from sibling tools like 'scoring-profile-get', which retrieves a single profile, though the verb 'list' implies multiple. It is clear but lacks explicit sibling distinction.

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 over alternatives. For instance, it does not explain when to use 'list' versus 'get', nor does it compare to other list tools on the server (e.g., company_lists-list). No usage context 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?

The description adds no behavioral context beyond what is already available in annotations. Annotations already indicate this is not read-only (readOnlyHint=false) and not destructive (destructiveHint=false), but the description does not elaborate on any side effects, auth requirements, or rate limits.

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 very concise with a single sentence, which is efficient. However, it could be slightly more informative without sacrificing brevity.

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 too minimal for an update operation. With no output schema, it should at least hint at the return value or confirmation. The lack of detail about what fields are updateable or the effect of the update leaves room for uncertainty.

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

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

Input schema coverage is 100%, with both parameters having descriptions. The description does not add any extra meaning beyond what the schema provides, so it meets the baseline expectation.

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 'scoring profile', making the purpose unambiguous. However, it does not differentiate from sibling tools like 'scoring-profile-create' or 'scoring-profile-delete', which share similar patterns.

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. There is no mention of prerequisites, when not to use it, or any contextual hints about its appropriate application.

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

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

Annotations already declare destructiveHint=true, idempotentHint=true, and readOnlyHint=false. The description adds no behavioral insights beyond what annotations provide. It does not contradict annotations.

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

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

A single, concise sentence that clearly communicates the tool's purpose with no extraneous information.

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

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

For a simple delete operation with well-defined inputs and comprehensive annotations, the description is complete enough. No output schema is needed, and the schema covers all parameters.

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?

Both parameters (ruleId, profileId) are fully described in the schema with format and description. The description adds no extra meaning, so baseline 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 'Delete a scoring rule', using a specific verb and resource. Among sibling tools like 'scoring-rule-upsert' and 'scoring-rule-list', this uniquely identifies the delete operation.

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

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

No explicit guidance on when to use this tool or alternatives. While the purpose is clear, there is no mention of prerequisites, irreversibility, or when to choose this over other rule-related tools.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the description carries less burden. However, it adds no additional behavioral context beyond the annotation set.

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

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

The description is a single, well-structured sentence that immediately conveys the tool's purpose with no 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?

The description is minimal but adequate for a simple list tool with robust annotations. It does not elaborate on output format or behavior like pagination, but given the low complexity, it meets minimum viability.

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 100% of parameter semantics with a description for profileId. The tool description adds no extra 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 'List scoring rules for a profile' uses a specific verb ('List') and resource ('scoring rules') with a clear scope ('for a profile'), distinguishing it from sibling tools like scoring-rule-delete and scoring-rule-upsert.

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 such as scoring-assignment-list or scoring-profile-list; the description lacks explicit 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?

Annotations indicate idempotentHint=true and destructiveHint=false, but the description adds no behavioral context (e.g., what happens on conflict, whether it merges or replaces). It does not contradict annotations but fails to enhance them.

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

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

The description is extremely concise (one sentence) but omits necessary details. It does not waste words, but it is under-informative for a tool with a complex nested input schema.

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

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

Given the complexity (nested body, multiple input variations), the description is too minimal. It does not mention return values, error handling, or side effects. No output schema exists to compensate, leaving the agent underinformed.

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 detailed descriptions for the nested body. The description adds no additional meaning beyond the schema, so baseline score of 3 applies.

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

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

The description 'Upsert a scoring rule' specifies the verb (upsert) and resource (scoring rule), but 'upsert' is a technical term that may be ambiguous. It does not clearly distinguish from sibling tools like 'scoring-rule-list' or 'scoring-rule-delete' beyond indicating a mutation.

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

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

No guidance on when to use this tool versus alternatives. With siblings like 'scoring-rule-delete' and 'scoring-rule-list', the description should explain when upsert is appropriate (e.g., create or update a rule).

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

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

The description adds no behavioral details beyond what annotations already provide (readOnlyHint, idempotentHint, etc.). It does not describe return format, pagination, or any side effects. There is no contradiction with annotations.

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

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

The description is a single, clear sentence that conveys the core purpose efficiently. It could be slightly more informative while staying concise, but it is not overly wordy.

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 lack of an output schema, the description should at least hint at the return format or structure of scores. The annotations help but do not compensate for the incomplete specification of what the tool returns.

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 does not add any information about the parameters beyond what is in the input schema. The schema already describes objectId usage, but objectType is only defined as an enum with no further explanation in either the schema or description.

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 'read' and the resource 'scores for one or more objects', which is sufficient for a basic understanding. However, it does not explicitly specify the object types (company/contact) or differentiate from sibling scoring tools like scoring-compute.

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. For example, it does not mention that this reads existing scores while scoring-compute might calculate new ones.

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

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

Annotations indicate write operation; description adds minimal context beyond stating it schedules execution. No disclosure of specific side effects or restrictions.

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

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

Single sentence, concise, and front-loaded with the core action. No unnecessary words.

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

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

The description omits critical details like required listId, optional templateId, mutual exclusion of frequency and cronExpression, and whether inline creation is possible. Insufficient for a complex 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 description does not need to add parameter details. The description's mention of 'domain' does not map to any schema parameter, but overall it does not mislead.

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

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

The description clearly states it schedules recurring signal execution, but mentions 'domain' which is not a parameter, causing slight ambiguity. It distinguishes from sibling tools by focusing on creation.

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

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

No guidance on when to use this tool versus alternatives like signal_subscriptions-start or -trigger, nor any prerequisites (e.g., requiring a list or template).

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

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

The description is consistent with annotations (read-only, non-destructive, idempotent) but adds no behavioral context beyond them. It does not disclose what happens when the subscriptionId is not found, whether the data is cached, or what fields are included in the response, which is notable given the lack of an output 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?

At six words with the verb front-loaded ('Get a signal subscription by ID'), the description is maximally efficient with zero redundancy. Every word serves to identify the operation and resource scope.

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

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

For a single-parameter lookup tool with comprehensive safety annotations, the description meets minimum viability but lacks completeness given the absence of an output schema. It should ideally indicate that it returns subscription details or metadata, and mention 404-like behavior for missing IDs.

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

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

With 100% schema description coverage already defining subscriptionId as 'The unique identifier of the subscription,' the description adds minimal semantic value by mentioning 'by ID.' It does not provide usage examples, validation details beyond the UUID pattern, or clarify the relationship between this ID and other ID types in the sibling tools.

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

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

The description clearly states the verb ('Get'), resource ('signal subscription'), and lookup method ('by ID'), distinguishing it from sibling operations like signal_subscriptions-list, -create, or -update. However, it does not clarify how this differs from the similar market_signals-get_subscription tool or define what constitutes a 'signal subscription' in this domain.

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

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

The description provides no guidance on when to use this tool versus alternatives such as signal_subscriptions-list (for browsing multiple subscriptions) or market_signals-get_subscription. It omits prerequisites, error conditions (e.g., invalid UUID), or recommended usage patterns.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds the organizational scope boundary ('your organization') and implies full enumeration via 'all', but does not disclose pagination limits, rate limiting, or the nature of 'signal subscriptions'.

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

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

The description is a single, efficient sentence with zero redundancy. The essential information (action + resource + scope) is front-loaded and immediately comprehensible.

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 pagination-based list operation with robust annotations, the description is minimally adequate. However, it omits the return value structure (no output schema exists) and does not explain the pagination behavior implied by the presence of limit/offset parameters.

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

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

With 100% schema description coverage, the input parameters (limit, offset) are fully documented in the JSON schema. The description adds no additional parameter semantics, syntax guidance, or usage examples, meeting the baseline for high schema coverage.

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

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

The description clearly states the verb (List), resource (signal subscriptions), and scope (your organization). However, it does not explicitly differentiate from the similar sibling `market_signals-list_subscriptions` or clarify when to use this versus `signal_subscriptions-get` for single-record retrieval.

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

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

The description provides no guidance on when to use this tool versus alternatives like `signal_subscriptions-get` (single record) or `market_signals-list_subscriptions`. It lacks prerequisites, filtering capabilities, or pagination strategy 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?

While annotations declare idempotentHint=false and openWorldHint=true, the description adds no context about what behavioral consequences occur when starting a subscription (e.g., activating webhooks, initiating real-time data flow, billing implications). It does not explain the effect of calling start on an already-active subscription.

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 brief at four words, which prevents waste, but this conciseness manifests as under-specification rather than efficiency. Every sentence earns its place, but there is only one sentence that conveys no information beyond the tool name itself.

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 presence of multiple lifecycle siblings (create, stop, trigger, update) and state-changing annotations (idempotent=false), the description is incomplete. It fails to explain the subscription lifecycle state machine, side effects, or what 'starting' entails operationally, leaving critical gaps for an agent selecting between similar tools.

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

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

With 100% schema description coverage (the subscriptionId parameter is fully documented in the schema with format, pattern, and description), the description meets the baseline expectation. However, the description text itself adds no parameter context, syntax guidance, or examples beyond what the schema provides.

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 'Start a signal subscription' is a tautology that restates the tool name (signal_subscriptions-start → 'Start a signal subscription'). It identifies the verb and resource but fails to distinguish this operation from siblings like signal_subscriptions-create, signal_subscriptions-stop, or market_signals-resume_subscription.

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. It does not clarify whether 'start' applies to newly created subscriptions, stopped ones, or if it differs from 'resume' operations found in sibling tools. No prerequisites or state requirements are mentioned.

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

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

While annotations indicate the operation is non-destructive, non-idempotent, and modifies state (readOnlyHint: false), the description adds no context about what happens during stopping—such as whether the subscription can be restarted, if billing ceases immediately, or how this differs from deletion. It relies entirely on annotations for behavioral cues.

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 a single four-word sentence. While technically concise, it underutilizes descriptive space by failing to front-load critical distinctions (stop vs. pause) or behavioral context, resulting in efficient brevity without sufficient information density.

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 presence of numerous sibling tools with overlapping functionality (pause, delete, start, trigger), the description is incomplete. It fails to clarify the stop operation's reversibility, relationship to the 'start' sibling, or side effects, which are essential for correct agent selection among similar tools.

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

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

With 100% schema description coverage, the subscriptionId parameter is fully documented in the schema. The description adds no additional semantics, examples, or format guidance beyond the schema's UUID pattern and description, meeting the baseline for high-coverage schemas.

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 'Stop a signal subscription' essentially restates the tool name (signal_subscriptions-stop) without providing differentiation from siblings like signal_subscriptions-pause, market_signals-delete_subscription, or signal_subscriptions-start. It identifies the verb and resource but fails to clarify scope or distinguish between termination and pausing.

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 'stop' versus alternatives like 'pause' (temporary halt) or 'delete' (permanent removal), nor are prerequisites mentioned (e.g., subscription must be active). The description lacks explicit when-to-use or when-not-to-use 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?

Annotations indicate this is a non-read-only, non-idempotent, non-destructive action with open-world effects. The description adds the temporal context ('immediate') but fails to disclose what the 'run' actually does (e.g., whether it fetches data, generates signals, or runs asynchronously) or any side effects beyond the annotations.

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

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

The description consists of a single, efficient sentence with zero wasted words. It is appropriately front-loaded with the action verb and maintains focus on the core functionality without unnecessary verbosity.

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

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

Given the low complexity (single UUID parameter) and absence of an output schema, the description is minimally adequate. However, for a tool in a complex domain with many siblings, it lacks context about what the triggered run produces or whether the operation is synchronous.

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

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

With 100% schema description coverage, the input parameter 'subscriptionId' is fully documented in the schema itself ('The unique identifier of the subscription to trigger'). The description adds no additional parameter semantics, syntax, or format details beyond what the schema provides, warranting the baseline score.

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 ('Trigger') and resource ('signal subscription') and clarifies the scope with 'immediate run'. However, it does not explicitly differentiate from similar lifecycle siblings like 'signal_subscriptions-start' (which likely activates the subscription) or 'market_signals-trigger_subscription'.

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

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

The description provides no guidance on when to use this tool versus alternatives. It does not indicate that this is for immediate/one-time execution versus scheduled runs, nor does it clarify the distinction between 'triggering' (running) and 'starting' (activating) a subscription.

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

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

Annotations declare idempotentHint=true and destructiveHint=false, which align with 'update'. Description adds no extra behavioral context (e.g., whether it merges or replaces fields, required permissions). Adequate but minimal.

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

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

Single sentence, front-loaded with purpose. Efficient but lacks details that could reduce ambiguity. Slightly under-specified for a complex tool.

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

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

Given the complex input schema (nested object with many fields) and no output schema, the description should cover success/error behavior, partial vs full update, and omitted fields. None provided, leaving 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 provides 100% description coverage for all parameters, so description need not add parameter details. However, it does not summarize or clarify the nested request body structure beyond what schema provides, hitting baseline.

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

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

Description clearly states the tool updates a signal subscription (verb+resource). It distinguishes from siblings like create, stop, list by using 'update', but does not elaborate on what aspects are updated.

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

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

No guidance on when to use this tool vs alternatives such as signal_subscriptions-create for new subscriptions or market_signals-update_subscription for market signals. Missing context for prerequisites or recommended scenarios.

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

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

Annotations indicate not read-only, not idempotent, not destructive. Description adds that it generates an AI summary from completed signals, but doesn't disclose potential side effects (e.g., costing credits, creating a resource). Minimal additional context beyond 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?

Single sentence, no redundancy. Every word contributes meaning without unnecessary 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?

Given one parameter and no output schema, description adequately explains what the tool does and what it operates on. Could mention output format or that it creates a new summary, but not critical for basic usage.

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

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

Single required parameter 'domain' with full schema description. Description adds no extra semantics for the parameter beyond what schema provides (it already says 'The company domain...'). Baseline 3 due to high 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?

Description uses specific verb 'generate' and resource 'AI summary', explicitly stating it consolidates insights from completed company signals for a domain. Clearly distinguishes from siblings like signal_summaries-list which likely lists existing summaries.

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