StackFast FractWin Expert Brain

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

Annotations already indicate readOnlyHint=true, idempotentHint=true, destructiveHint=false. The description adds valuable context by confirming the packet is review-only and does not perform any autonomous actions, which aligns with and enhances the annotation hints.

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

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

The description is two sentences, front-loading the purpose and then adding behavioral context. Every sentence contributes meaning, and there is 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?

Despite having an output schema, the description lacks parameter documentation and does not explain what the callback packet contains or when tenant_id is needed. For a tool with two parameters and no schema descriptions, this is insufficient.

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 two parameters (call_id, tenant_id) with no descriptions, and the description does not mention any parameters. With 0% schema description coverage, the description fails to add meaning or clarify parameter usage.

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 returns a human-review callback packet for one AI Receptionist call. It includes a specific verb ('Return') and resource ('callback packet'), but does not explicitly differentiate from siblings like ai_receptionist_review_queue or ai_receptionist_status within the description itself.

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

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

The description provides context that the packet is review-only and does not send SMS, place calls, or reply autonomously, which implies when not to use it. However, it does not explicitly state when to use this tool versus alternatives or provide exclusions.

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

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

Annotations already declare readOnlyHint, destructiveHint, and idempotentHint, establishing safe read behavior. The description adds value by specifying that returns include callback and SMS status where present and that identifiers are masked/audit-safe, which is not in annotations. 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, clear sentence that efficiently conveys the tool's purpose and output. It could benefit from an additional line to explain parameters, but as is, it is concise 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 presence of an output schema (which documents return values) and annotations covering safety, the description adequately covers tool behavior and output. The main gap is parameter semantics, but the tool is simple with only two optional parameters, so the description is mostly complete.

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

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

With 0% schema description coverage, the description must compensate for missing parameter details, but it does not mention 'limit' or 'tenant_id' at all. The description focuses on output behavior (masked IDs, callback/SMS) but ignores input semantics, leaving the agent without guidance on how to use the 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 lists 'recent AI Receptionist call-loop receipts for human review' with specific detail about including callback and A2P-gated inbound SMS status. The phrase 'returns masked/audit-safe identifiers only' further clarifies the scope, distinguishing it from other AI Receptionist tools like ai_receptionist_callback_packet.

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

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

The description indicates the tool is for 'human review' of call-loop receipts, which provides clear context. However, it does not explicitly state when not to use it or mention alternative tools such as ai_receptionist_status. The purpose is clear but lacks exclusion guidance.

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

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

Annotations already indicate readOnly, idempotent, and non-destructive behavior. The description adds valuable context by listing exactly what data sources are read and that results are masked/status only, enhancing transparency 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?

Single, concise sentence that front-loads the action and key details without any redundant or filler 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 presence of an output schema, the description adequately covers the input context (a call ID) and output nature (masked/status metadata). Minor gap: it could note that only one call ID is supported.

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

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

With 0% schema description coverage, the description partially compensates by identifying call_id as the key identifier ('for one AI Receptionist call ID'), but it does not clarify the optional tenant_id parameter or its purpose.

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

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

Description uses specific verbs ('Read') and resources ('Desk ticket, CRM callback task, call-link receipt, A2P-gated inbound SMS posture') for one AI Receptionist call ID, clearly distinguishing it from sibling tools like ai_receptionist_callback_packet.

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

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

The description implies this tool is for reading status metadata for a single call ID, but does not explicitly state when to use it versus alternatives (e.g., ai_receptionist_callback_packet) or provide any when-not-to-use guidance.

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

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

Annotations already indicate read-only behavior. The description adds value by disclosing that V1 intentionally omits raw artifact contents, which is a key behavioral trait beyond the annotation.

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 with two sentences, no fluff, and front-loaded with the 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?

The description covers basic purpose but lacks details on parameter roles, pagination (given the limit parameter), and output structure even though an output schema exists. It is adequate for a simple tool but leaves some 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 0%, and the description provides no additional meaning for any of the 4 parameters. The parameter names are self-descriptive, but the description does not clarify usage or relationships.

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 returns session artifact metadata and persistent URLs, and explicitly notes that V1 omits raw contents. This is a specific verb+resource combination and distinguishes from sibling tools which have different purposes.

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

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

There is no guidance on when to use this tool versus alternatives like 'fetch' or other sibling tools. No context on 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 provide readOnlyHint=true. Description adds context on what is read (state, refs, ledger, links) but lacks behavioral details like permissions or error behavior.

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

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

Single sentence is concise but omits critical information about parameters. Could be expanded without losing 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?

Despite having an output schema, the description only partially covers return content. Parameter semantics are absent, making it incomplete 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?

Schema description coverage is 0% and the description does not explain either parameter (tenant_id, audit_project_id), leaving them entirely ambiguous.

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 reads 'AI Stack Audit project state, deliverable refs, credit ledger, and Desk/CRM links', using a specific verb and resource. It distinguishes from siblings which focus on different domains (e.g., growthos, talent scout).

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 vs alternatives. Siblings like artifact_get may also read project data but no comparison or exclusions provided.

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

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

Annotations already provide readOnlyHint, idempotentHint, destructiveHint. Description adds that the tool 'does not expose secrets', which is useful security 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?

Two concise sentences with no redundant information. Every word adds value.

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

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

The description fully covers the tool's purpose, behavior, and security implications. Given no parameters and presence of output schema, it is 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?

No parameters exist, so schema coverage is 100% trivially. Description adds context about the tool being a health check, which is sufficient for understanding what the tool does without 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?

Description clearly states 'StackFast connector health/status check' which is a specific verb (check) and resource (connector health). No siblings exist, so differentiation is not required.

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?

Description implies usage for health checking, but does not explicitly state when to use or alternative tools. Since there are no sibling tools, the guidance is adequate.

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 behavioral context beyond annotations: it states it 'never returns raw credentials' and specifies returned data types (service slugs, env/key aliases, categories, resolver guidance). This aligns with the readOnlyHint annotation 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 concise with two sentences, front-loading the purpose and usage. No redundant 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 tool has an output schema, the description sufficiently covers return values and behavior. It addresses use cases and what the tool does not do, making it complete for its complexity.

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

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

The description does not elaborate on the 'query' parameter beyond the schema, which already has 100% coverage with clear examples. Baseline 3 is appropriate as description adds minimal value for 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 explicitly states the tool discovers 'wallet-resolved credential service names and accepted aliases without exposing secret values.' This specific verb and resource clearly distinguishes it from sibling tools like 'fetch' or 'search' which deal with different 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 provides explicit guidance: 'Use this when an agent is unsure whether a key exists, sees a key-not-found error, or needs the canonical getAgentKey(service) name.' It also implies not to use for retrieving secrets, covering both when and when not to 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 indicate readOnlyHint=true, so the tool is read-only, but the description says 'Operate on,' which could imply mutations. It adds no behavioral context beyond the annotations, and the vague wording might confuse agents.

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

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

The description is only one sentence, which is concise, but it sacrifices clarity for brevity. It lacks structure and does not effectively communicate the tool's function.

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 13 parameters, an output schema, and complex nested objects, the description is severely incomplete. It provides no information about return values, parameter relationships, or expected behavior, leaving the agent with minimal guidance.

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 schema description coverage at only 15%, the description should explain key parameters but fails to mention any. The tool has 13 parameters, and the description adds zero information about their meaning or usage.

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 generic phrase 'Operate on' and does not specify the exact action (e.g., search, list, filter). The title mentions 'catalog search' but the description fails to confirm this, making the tool's core purpose unclear.

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 sibling tools like 'search' or estimator_estimate_* tools. There are no conditions, 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 says 'Operate' which is neutral, but the name implies a write operation (add line). Annotations declare readOnlyHint=true, contradicting the name. The description adds no behavioral context beyond the annotations, failing to resolve this confusion or disclose consequences.

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 but is overly broad and uninformative. It is concise in length but not in value; every part of the sentence is generic and fails to convey the tool's specific 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 complexity (13 parameters, nested objects, output schema exists), the description is severely incomplete. It does not state the primary action, required parameters, or what the tool returns. The output schema is not provided, but even if it were, the description fails to guide tool selection.

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?

Only 2 out of 13 parameters have descriptions in the schema (15% coverage). The description adds no parameter information, leaving most parameters completely undocumented. Baseline is low due to high parameter count and low schema coverage.

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

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

The description is extremely vague, stating 'Operate on tenant-scoped OCE Estimator/Appraiser drafts, lines, versions, documents, exports, and policy receipts.' It does not specify that the tool adds a line to an estimate, as the name suggests. The description is a generic list of entities, not a clear verb+resource statement.

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 usage guidance is provided. The description does not indicate when to use this tool versus sibling tools like estimator_estimate_update_line or estimator_estimate_create_draft. There is no mention of context, prerequisites, or alternatives.

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

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

Annotations declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, indicating a safe read-only operation. However, the name 'convert_to_bid' and the verb 'Operate' imply a mutation, creating a contradiction. The description does not resolve this or disclose any behavioral traits such as required permissions, side effects, or return behavior, which is critical given the 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 sentence, but it is under-specified and lacks focus. While short, it is not concise because it uses vague language ('Operate on...') that adds little value. Every sentence should earn its place; this one does not.

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 high parameter count (13), nested objects, and the presence of an output schema (not shown in description), the description is completely inadequate. It fails to explain what the tool does, what inputs are expected, or what output results. The tool is complex, and the description provides no meaningful context for understanding its functionality.

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

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

Schema description coverage is only 15%. The description adds no parameter information beyond the schema. Only two parameters (tenant_id and adapter_id) have brief descriptions in the schema. Many parameters are opaque objects with no description, and the description does not explain their roles. The tool's complexity demands more parameter clarity.

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

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

The description 'Operate on tenant-scoped OCE Estimator/Appraiser drafts, lines, versions, documents, exports, and policy receipts' is vague and does not state the specific action of converting an estimate to a bid. The name 'convert_to_bid' suggests a specific operation, but the description broadens it to generic 'operate', failing to clarify the tool's core purpose. It does not distinguish this tool from sibling tools like estimator_estimate_convert_to_invoice.

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, constraints, or scenarios where this tool should or should not be used. The description lacks any 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 provide readOnlyHint=true, idempotentHint=true, destructiveHint=false. The description adds 'Review-gated' which clarifies access control, and 'does not write to accounting systems' reinforces the read-only nature. No contradictions.

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

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

Two sentences, front-loaded with purpose, followed by constraints. No redundant words. Efficient.

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

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

Although an output schema exists, the description is too brief for a tool with 13 parameters, nested objects, and enums. It does not explain what 'prepare' entails, what 'QBO handoff' means, or how the 'review-gate' works.

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 13 parameters and only 15% schema description coverage, the tool description provides no parameter-level details. It does not explain the purpose of 'line', 'lines', 'query', 'bridge', etc. The descriptions in the schema for 'adapter_id' and 'tenant_id' are present but are not supplemented in the tool 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 verb 'Prepare' and the resource 'OCE Estimator/Appraiser document or QBO handoff contract'. It distinguishes from sibling tool 'estimator_estimate_convert_to_bid' by mentioning 'QBO handoff' and 'does not write to accounting systems'.

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 'Review-gated; does not write to accounting systems', which implies when to use (after review, for document generation not final booking) but does not explicitly state when not to use 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?

The annotations declare readOnlyHint=true, but the tool name implies a write operation ('create draft'). This contradiction is misleading. The description does not disclose behavioral traits beyond annotations, failing to resolve the inconsistency.

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 tries to cover many entity types and actions, making it verbose yet vague. It is not concise and lacks structure, such as bullet points or clear separation of concerns.

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 13 parameters, many undocumented, and an existence of an output schema (not shown), the description fails to provide essential context. The tool's complexity is not addressed, leaving the agent with insufficient information to invoke it correctly.

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

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

Schema description coverage is only 15% (2 out of 13 parameters have descriptions). The description adds no meaning to the many undocumented parameters like 'line', 'lines', 'query', etc. The tool needs to explain parameter purposes, especially nested objects.

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 'Operate on tenant-scoped OCE Estimator/Appraiser drafts, lines, versions, documents, exports, and policy receipts' is vague and does not specify that this tool creates a draft estimate. The name suggests creation but the description covers many possible operations, lacking clarity.

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

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

No guidance is provided on when to use this tool versus sibling tools like estimator_estimate_add_line or estimator_estimate_export. The description does not indicate prerequisites or alternatives.

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

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

Annotations already provide readOnlyHint=true and idempotentHint=true, but the description adds no additional behavioral context. It is too vague to clarify read-only or export behavior.

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

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

The description is a single, short sentence, but it is under-specified. Conciseness is good, but it sacrifices clarity.

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

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

Given the high parameter count, numerous siblings, and no output schema details, the description is entirely inadequate for an agent to use this tool correctly.

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

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

Schema has 13 parameters with only 15% description coverage. The description does not explain any parameters, leaving the agent to guess their meaning based solely on names.

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 says 'Operate on...' which is vague and does not specify that this tool exports estimates. The name suggests export, but the description lists many entities without stating the action.

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

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

No guidance on when to use this tool versus siblings. There are many similar estimator tools, but the description provides no context for selection.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false. The description adds 'Review-gated' and 'does not write to accounting systems,' which aligns with and enriches the annotations. It provides useful context about the workflow 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?

Two short sentences, front-loaded with purpose. No wasted words. Could be improved by including parameter hints, but for its length it is efficient.

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

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

Given the tool's complexity (13 parameters, nested objects, output schema exists), the description is too sparse. It does not explain the document preparation process, parameter roles, or how the review gate works. Despite having an output schema, the agent needs more context to use the tool correctly.

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

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

Description coverage of input schema is only 15%, and the description does not compensate. It provides zero information about any of the 13 parameters, including those with enums or descriptions. The description fails to add meaning beyond the schema, leaving the agent without guidance on how to populate 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 states a specific action ('Prepare') and resource ('OCE Estimator/Appraiser document or QBO handoff contract'), which is clear. However, it does not explicitly mention 'progress invoice' despite the tool name, creating slight ambiguity. It distinguishes from sibling tools like estimator_estimate_convert_to_invoice by focusing on document preparation.

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 some guidance: 'Review-gated; does not write to accounting systems.' This implies a safe, draft-like usage. However, it does not explicitly state when to use this tool vs. alternatives (e.g., converting an estimate to invoice) 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?

The description adds little beyond annotations. It lists resources but does not clarify behavior. Although annotations declare readOnlyHint=true, the tool name 'update' suggests mutation, creating confusion. The description does not address 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 sentence but is too vague to be useful. It lists many entities without focusing on the tool's specific role, making it unhelpful.

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 (13 parameters, nested objects, output schema), the description is grossly inadequate. It does not explain what the tool does, how to use it, or what output to expect.

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

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

Schema description coverage is only 15%, and the description contains no information about parameters. It does not explain the purpose or usage of any of the 13 parameters, leaving the agent with minimal guidance.

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 is overly broad, stating 'Operate on tenant-scoped OCE Estimator/Appraiser drafts, lines, versions, documents, exports, and policy receipts.' It does not specify that this tool updates a line, as implied by the name. It also fails to distinguish from sibling tools like estimator_estimate_add_line.

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. Does not mention any prerequisites, exclusions, 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 declare readOnlyHint=true, so the agent knows it is a safe read operation. The description adds 'tenant-scoped' and lists entities, but does not disclose what the tool actually returns or any behavioral traits beyond what annotations provide.

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

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

The description is a single sentence, which is concise, but it fails to convey substantive information. It uses vague language and does not earn its place with useful content.

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

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

Given the high parameter count (13) and low schema coverage (15%), the description is incomplete. It does not explain the tool's purpose, output, or how parameters interact, leaving significant gaps for the agent.

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

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

Only 15% of parameters have descriptions in the schema, yet the description provides no explanation of the 13 parameters. It adds no meaning to the input schema, leaving the agent without guidance on which parameters to use or how they relate.

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 'Operate on' as the verb, which is vague and does not specify the actual action (e.g., 'list', 'check', 'validate'). The title suggests 'policy check', but the description fails to clarify. It lists multiple entity types without indicating what the tool does with them.

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

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

No guidance is provided on when to use this tool versus the many estimator_ sibling tools with specific actions (e.g., add_line, convert_to_bid). The agent lacks context on the intended use case or alternatives.

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

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

Annotations already declare readOnlyHint=true and idempotentHint=true, indicating safe, read-only behavior. The description adds no further behavioral context (e.g., authentication, rate limits) and uses the ambiguous verb 'operate,' which could mislead. No contradiction with annotations, but no added 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?

The description is a single sentence, but it is under-specified and fails to convey essential information. Conciseness does not compensate for lack of substance.

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 (13 parameters, nested objects, output schema, many sibling tools), the description is grossly inadequate. It does not explain what the tool returns, how to use parameters, or when to prefer it over alternatives.

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

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

Schema description coverage is only 15%, yet the description provides no parameter-level information. It mentions none of the 13 parameters, leaving the agent without guidance on how to populate them. This is a critical gap.

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

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

The name 'estimator_receipt_get' and title clearly indicate getting a receipt. However, the description uses the vague verb 'operate' without specifying retrieval, and fails to differentiate from sibling estimator tools that also deal with similar entities.

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 is too generic to help an agent decide under what conditions to invoke this tool.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false. Description adds minor implementation detail ('AI6 MCP reader plane') but no behavioral 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, front-loaded with verb and resource. Zero wasted words, optimally sized.

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?

Simple tool with one parameter, full annotations, and an output schema. Description provides sufficient context for a fetch-by-id operation without needing to explain return values.

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

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

Schema covers 100% of parameters with clear description and example. Description adds no extra meaning beyond 'by id'. Baseline 3 applicable.

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 'Fetch' and resource 'StackFast Brain search result', clearly distinguishing from sibling tool 'search' which creates results. The 'by id' qualifier makes scope 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?

Implies that the id must be obtained from a prior search (e.g., 'search' tool), but lacks explicit when-to-use or alternatives. No direct exclusions or usage caveats.

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 contradicts the annotation readOnlyHint=true by stating it can 'start' or 'append,' which implies write operations. This is a clear contradiction. The description adds one behavioral note about output state but is overall misleading.

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, which is concise, but it lacks structure and does not efficiently convey necessary information. The sentence is somewhat vague and could be front-loaded with 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?

Given the complexity of the tool (11 optional parameters, 2 enums, multiple actions), the description is far from complete. It fails to cover the action enum, parameter roles, or output semantics, relying entirely on schema and 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?

With 0% schema description coverage and the description failing to explain any of the 11 parameters, there is no added semantic value. The description offers no details on how parameters like 'action', 'source', or 'answers' are used.

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 tool starts or appends a GrowthOS Business Brain Interview, referencing a specific model. This gives a clear verb and resource, but does not differentiate from sibling tools like growthos_scorecard, which may have overlapping functionality.

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

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

No guidance is provided on when to use this tool versus alternatives. It lacks any context about prerequisites, when to perform start vs append, 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 readOnlyHint=true, idempotentHint=true, destructiveHint=false. The description adds context about 'draft' nature and the condition for returning draft_review_required, but does not disclose additional behavioral traits beyond what annotations provide.

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

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

Two sentences that are front-loaded with the core purpose and inputs, followed by constraints. No extraneous words, every sentence 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 has nested objects and an output schema, the description adequately covers the input context and conditions. The output structure is not explained, but output schema exists to cover that.

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

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

Schema description coverage is 100%, and the description repeats the schema descriptions verbatim without adding new meaning. Baseline 3 is appropriate as no extra value beyond schema.

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

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

The description clearly specifies the verb 'Build', the resource 'draft GrowthOS digital-clone render packet', and the inputs: 'normalized signals, evidence, runtime tenant voice profile, and PERSPECTIVE capability grounding'. It also includes negative constraints ('No Robert voice defaults and no autonomous outbound'), distinguishing it from sibling tools like growthos_business_brain_interview.

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 required inputs (tenant_profile, prospect) and a condition ('missing profile returns draft_review_required'). It includes a negative constraint but does not explicitly compare to sibling tools or specify when to use this tool over alternatives.

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

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

Annotations already indicate readOnlyHint, idempotentHint, and destructiveHint. The description adds valuable behavioral context by describing the use of a 'gate-first policy layer' and stating that no new persistence table is created, 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?

The description is a single, well-structured sentence that front-loads the main action and key details, with no extraneous 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 nested object parameter and the presence of an output schema, the description adequately covers the tool's function (types, policy layer, persistence). It is complete enough for an agent to understand the tool's role without needing further details about return values.

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 one parameter, and the schema description already specifies the opportunity_type constraint. The tool description adds context about the types of opportunities, but the parameter semantics are largely covered by 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 action ('Build') and the resource ('Opportunity Scout packet'), lists the specific types (customer, talent, contract, capital), and references a distinguishing policy layer, differentiating it from sibling tools like growthos_revenue_capture_packet.

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 building packets for the listed opportunity types but does not explicitly state when to use this tool versus alternatives (e.g., growthos_revenue_capture_packet, talent_scout_create_packet), nor does it provide when-not-to-use guidance.

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

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

Annotations indicate readOnlyHint=true, idempotentHint=true, destructiveHint=false. The description adds that the tool does not send autonomously and includes optional composition behavior, providing context beyond 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, front-loaded sentence of 25 words with no wasted text, conveying the essential action and constraints 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?

With annotations and output schema present, the description covers the main purpose and behavioral note. However, it omits explanation of 'step 3' referenced in the schema and the report content beyond 'scorecard.'

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

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

Schema description coverage is 50% (only CogentCast params documented). The tool description does not explain the 'sender' or 'prospect' parameters, failing to add meaning beyond the schema for those critical 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 tool renders a scorecard into a sendable report with multiple output formats (web, email, PDF) and optional CogentCast composition. It uses specific verbs and resources, and distinguishes from sibling tools like growthos_scorecard.

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

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

The description explicitly says 'No autonomous send,' telling the agent the tool does not send the report. However, it does not provide explicit guidance on when to use versus alternatives or when not to 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 readOnlyHint=true; description adds value by stating 'No autonomous outbound' and explaining that the tool may fetch a CogentCast receipt (a read operation). No contradiction with annotations.

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

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

Two concise sentences that front-load the output and input. No filler, but could be slightly more structured (e.g., bullet points for components). Still well within acceptable bounds.

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 (4 parameters with nested objects, output schema exists), the description adequately lists output components but does not clarify input mapping, prerequisites, or dependencies. Output schema handles return details, but input guidance is missing.

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?

Only 50% of parameters have descriptions in the schema; the tool description does not compensate for undocumented parameters like 'sender' and 'prospect'. It mentions 'supplied local-business evidence' but fails to map this to specific parameters or explain their structure.

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 what the tool does: returns a revenue-capture packet with specific components (scorecard, contact drafts, CogentCast receipt composition, summary) for local-business evidence. It distinguishes from siblings by naming unique output elements and mentioning CogentCast integration.

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 local-business evidence with optional CogentCast receipt, but lacks explicit when-to-use or when-not-to-use guidance. No comparisons to sibling tools like growthos_opportunity_scout_packet, leaving ambiguity for an AI agent.

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. The description adds context: 'private', 'never sends outreach', and 'returns findings only', reinforcing safe, read-only behavior. 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?

Two sentences with no wasted words. The key action and constraints are front-loaded. Perfectly sized 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 presence of annotations and output schema, the description adequately covers purpose and key behavioral traits (private, no outreach). It does not explain what a scorecard entails, but the tool name and context imply it. Minor gap.

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

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

Schema coverage is 100%, so the schema already describes the three parameters (sender, prospect, prospects). The description does not add extra detail beyond 'supplied public business signals', so baseline 3 is appropriate.

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

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

The description clearly states the action (build), the resource (private GrowthOS Revenue Capture Scorecard), input (public business signals), and output (scorecard findings). It also distinguishes itself by noting it never sends outreach, contrasting with sibling outreach tools.

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

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

While the description implies use for scorecard building and analysis-only (no outreach), it does not explicitly state when to use this tool versus other GrowthOS packet tools (e.g., growthos_opportunity_scout_packet). No exclusions or alternatives 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 and destructiveHint=false. Description adds that it operates through the AI6 MCP reader plane and returns result ids, which provides useful behavioral 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 that front-loads the purpose and includes actionable instruction. 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?

Output schema exists, so description need not detail return values. It mentions using fetch with result id, which is helpful. Could mention pagination or result format but not necessary for this simple 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 has 100% coverage with description for 'query'. Description adds that it searches StackFast Brain knowledge but does not add syntax or formatting details beyond schema, 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 it searches StackFast Brain knowledge and differentiates from the sibling 'fetch' tool by instructing to use fetch with returned result id for full text.

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 use fetch for full text after search, providing clear next step. Does not explicitly list when not to use this tool versus other search tools, but context 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?

Beyond readOnlyHint and destructiveHint annotations, the description adds value by specifying exactly what is and isn't returned (e.g., 'never returns raw resume, LinkedIn, claims, or private applicant text'). This helps set expectations without contradicting annotations.

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

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

Two tightly written sentences with no fluff. Front-loaded with purpose and immediately followed by concrete behavioral constraints. Every sentence 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 presence of output schema (which details return structure) and annotations (which cover safety), the description is complete. It explains redaction scope, tenant scoping, and what is excluded, which is sufficient for this read-only status tool with 0 required 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 80% schema description coverage (4 of 5 parameters documented in schema), the description itself adds no parameter-level detail. The undocumented 'tenant_id' parameter could have been explained here but wasn't. Baseline 3 is appropriate as schema carries most of the 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?

Description clearly states verb ('Read'), resource ('redacted status for the tenant-scoped Talent Scout applicant profile'), and outcome ('Returns presence, counts, profile id, and compose readiness only'). Distinguishes from sibling tools like 'talent_scout_applicant_profile_upsert' which is write-oriented.

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?

While no explicit when-not-to-use or alternatives are named, the description clarifies that the tool never returns raw resume, LinkedIn, etc., guiding agents away from using it for such data. For a read-only status check among many siblings, this provides some directional clarity.

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 claims 'Create or update' (a write operation), but the annotations set readOnlyHint=true, contradicting the description. While the description adds value by stating that raw text is never returned, the contradiction severely undermines trust.

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

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

Two sentences, 56 words, front-loaded with purpose and benefit, no wasted language.

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

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

Despite the complexity of 23 parameters, the description fails to cover key aspects like mode, dry_run, database routing, and most parameter groups, leaving the AI 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?

With only 35% schema description coverage, the description should compensate but only gives a high-level overview of stored fields (resume, LinkedIn, proof-points, etc.) without explaining most parameters individually.

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 'Create or update the tenant-scoped Talent Scout applicant profile' with a specific verb and resource, and explains the benefit of reuse by other tools, distinguishing it from sibling tools like status, compose, and score.

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

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

The description implies that this tool should be used before compose, score, and packet tools to avoid re-pasting data, but it does not explicitly state when to use it versus alternatives or provide exclusions.

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

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

Annotations already provide readOnlyHint=true and non-destructive flags. The description adds 'Draft/review only; no sends or applications,' reinforcing safety and clarifying the tool's limited scope. 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 long sentence listing many items, which is moderately concise but could be more structured. Front-loaded with the core action ('Build the recruiting-desk workup'), but the variety of items makes it dense.

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 full scope of the workup components, and the existence of an output schema means return values don't need elaboration. Combined with siblings context, it provides sufficient completeness for an agent.

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

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

With 43% schema description coverage, the description does not elaborate on parameters beyond what the schema provides. The tool's purpose is clear, but param-level details are missing. List of workup components gives some context but not direct parameter semantics.

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

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

The description clearly states the verb 'Build' and the resource 'recruiting-desk workup', listing many specific components (e.g., availability status, fit risks, application packet). It distinguishes from siblings like 'talent_scout_compose_application' by emphasizing the comprehensive workup nature.

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

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

The description indicates it's for one Talent Scout queue item and is draft-only, but does not explicitly compare to alternatives (e.g., when to use this vs talent_scout_compose_application). It provides identification context (queue_item_id or title+company) but lacks when-not-to-use guidance.

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

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

The annotations already declare readOnlyHint=true and destructiveHint=false. The description adds significant behavioral detail: 'draft-only', 'fails closed on generic fallback text', 'bounded for hosted MCP latency', and the constraint on output kinds. No contradictions with annotations.

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

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

Two sentences, each adding distinct value: first states purpose, second adds constraints and supported types. No wasted words. Front-loaded with core 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?

An output schema exists, so return values need not be explained. The description covers output kinds, failure mode, and bound. However, with 18 optional parameters, it lacks guidance on how to combine them (e.g., queue_item_id vs title+company pairing), which would improve completeness for an agent.

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

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

Schema description coverage is 67%, so the schema already documents most parameters. The description does not elaborate on parameter usage beyond implying queue_item_id is primary. It adds minimal value over the schema's parameter descriptions.

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

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

The description clearly states the verb ('Compose'), the resource ('draft-only job-seeker application artifact'), and the source ('from a real Talent Scout queue item'). It also lists specific output types and explicitly says 'never sends or applies', distinguishing it from sibling tools like talent_scout_draft_outreach that likely involve sending.

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 composing drafts from queue items but does not explicitly state when to use this tool versus siblings. It mentions 'only; never sends' which helps avoid misuse, but lacks direct comparisons or conditions for alternative tools like talent_scout_score_fit or talent_scout_search_opportunities.

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 claims the tool creates (write) a packet, but annotations indicate readOnlyHint=true, which suggests the tool is read-only. This is a direct contradiction. No other behavioral traits are disclosed beyond the annotation conflict.

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

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

The description is two sentences, front-loading the primary action and necessary note about human approval. No filler or redundant information.

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

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

Given 6 parameters, a required queue_item_id, and an output schema, the description lacks parameter details and behavioral completeness. The annotation contradiction undermines trust, and the description does not cover outcomes or usage constraints beyond creation.

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

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

With 0% schema description coverage, the description should compensate by explaining key parameters. It only hints at queue_item_id ('from an existing queue item') but fails to describe actor_id, tenant_id, output_kind, opportunity_mode, or notes. The meaning of these parameters is entirely absent.

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 draft-only application or opportunity packet from an existing Talent Scout queue item. It distinguishes from siblings like talent_scout_draft_outreach (outreach drafting) and growthos_opportunity_scout_packet (different context).

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 tool is for creating a packet from a queue item and notes human approval is required. It implies when to use but does not explicitly exclude alternatives or state when not to use. Sibling names provide context but description lacks explicit guidance.

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

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

Annotations declare readOnlyHint=true, idempotentHint=true, destructiveHint=false. The description adds context: mailbox reconciliation runs server-side via StackFast, it never applies or sends, and it is a read-only control-tower view. No contradictions with annotations.

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

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

The description is relatively long (6-7 sentences) but each sentence adds essential detail about behavior, constraints, or output. It is front-loaded with the main purpose and maintains clarity, though minor trimming could improve 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 tool's complexity (10 parameters, nested objects, important constraints), the description is highly comprehensive. It covers purpose, usage rules, behavioral traits, and output components. Since an output schema exists, return values don't need detailed explanation, but the description still provides high-level output structure.

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 descriptions cover 60% of parameters, including core ones like compact, hydration_limit, and include_applied. The description adds practical context (e.g., compact defaults true for latency, hydration_limit never applies or sends). This adds value beyond the schema, justifying a score above baseline 3.

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

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

The description explicitly states it returns the 'closed-loop Talent Scout daily operating report' and lists many specific components (applied pipeline, mailbox reconciliation, etc.). It clearly distinguishes from sibling tools like talent_scout_review_queue and talent_scout_application_workup.

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

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

The description provides explicit instructions: clients must not use their own email connector; if mailbox status is not ok, stop and surface red receipt. It also states 'Read-only control-tower view; no sends or applications,' clearly indicating when to use (read-only reporting) and when not to (no writes).

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false. The description adds valuable behavioral context: the strategy order, that listings are treated as leads not truth, return content (scored targets, confidence, receipts, next actions), and explicit exclusions (no LinkedIn scrape, no outreach). No contradiction with annotations.

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

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

Two sentences, front-loaded with core purpose and strategy, no redundant information. Every word adds value.

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

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

Given the complexity (11 parameters, multiple database routing options) and that output schema exists, the description covers the primary intent but omits edge cases, prerequisites, and guidance on when to use optional parameters like tenant_database_type or auth_token_key.

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 55%, so description partially compensates. The description does not elaborate on individual parameters beyond the implication of a campaign context. Key parameters like limit, sources, tenant_id have no schema descriptions, and the description does not address them.

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 ('Run company-first discovery'), the resource ('from a saved campaign'), and the specific methodology ('chamber/member-directory strategy'). It distinguishes itself from sibling tools by specifying it does not scrape LinkedIn or send outreach.

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 starting from a saved campaign and not needing LinkedIn scraping or outreach, but does not explicitly state when to use this tool versus alternatives like talent_scout_discover_local_companies. No prerequisites or when-not conditions 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 set readOnlyHint=true, indicating a read-only operation. The description's wording ('Run the pipeline') could be misinterpreted as a mutation, but no direct contradiction exists. The description adds no additional behavioral context (e.g., data returned, side effects), so it relies on annotations; a neutral score is appropriate.

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

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

The description is two concise sentences, front-loaded with the primary action. It avoids verbosity and focuses on the core purpose. However, the structure could be improved (e.g., bullet points for constraints) for faster scanning.

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

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

Despite having an output schema (as per context), the description does not explain what the pipeline returns or how to interpret results. With 17 parameters and low schema coverage, the description lacks context on parameter relationships, default behaviors, or the discovery process. The tool is complex but the description provides only high-level constraints, falling short of completeness.

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

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

Schema description coverage is low (35%), with only 6 of 17 parameters having descriptions. The tool description does not add any parameter-level meaning or clarify critical parameters like geography_anchor, radius_minutes, or limit. The user must infer parameter roles from names and minimal schema hints, which is insufficient for a 17-parameter configurable pipeline.

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 runs a 'local company-discovery pipeline' and specifies key constraints (company leads only, websites required, dynamic size band, careers-page verification). It also identifies itself as a 'job-named alias' for server-side discovery, providing some differentiation from siblings like 'talent_scout_discover_companies_by_campaign', though the distinction could be more explicit.

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

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

No explicit guidance on when to use this tool vs. alternatives. The description implies it is for local company discovery with specific requirements, but does not mention when not to use it or suggest sibling tools. Given many similar talent_scout tools exist, this omission hampers correct selection.

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

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

Annotations (readOnlyHint=true) already indicate no side effects, and the description reinforces this with explicit constraints: 'No autonomous send, no LinkedIn scraping, no fake relationships, and no invented jobs.' This provides added behavioral context beyond annotations, with 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?

The description is extremely concise – two sentences that front-load purpose and immediately list boundaries. Every word serves a clear function, with no redundancy or filler.

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

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

Given 14 parameters (0 required) and an output schema, the description covers core intent and boundaries but lacks guidance on optional parameter usage and their interrelationships. It is minimally complete for a drafting tool but could be more informative about 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 low (29%), yet the description adds minimal parameter guidance beyond mentioning channels. Parameters like 'goal', 'send', 'apply' are not explained in the description, leaving the agent without semantic help for most 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 drafts human-reviewed direct outreach for qualified company/contact and campaign, and specifies supported channels (LinkedIn, email, phone, in-person). It distinguishes from the sibling 'talent_scout_draft_outreach' by focusing on direct outreach and listing exclusions, making purpose unambiguous.

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

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

The description provides clear context on what the tool drafts (scripts) and what it does not do (autonomous send, scraping, fake relationships, invented jobs). However, it does not explicitly name alternative tools or when-not-to-use scenarios relative to siblings like 'talent_scout_draft_outreach'.

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

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

The description discloses that the tool never sends messages and fails closed on auto-send/apply requests, adding value beyond annotations. However, annotations mark readOnlyHint as true, suggesting no writes, while 'drafting' could imply creating a draft artifact. This ambiguity prevents a higher 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?

The description is two sentences long, front-loaded with the core purpose, and every sentence adds value. No fluff or repetition.

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

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

With 8 parameters (2 required), an output schema existing, and no nested objects, the description is adequate but minimal. It covers key points but omits parameter details and return value hints, which could be expected given complexity. The output schema partially compensates for missing return info.

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

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

The description references pains and voice evidence but does not explain the send, apply, artifact_type, or tenant_id parameters. With 0% schema description coverage, the tool description should compensate, but it fails to clarify the role of these fields, making it harder for an agent to use correctly.

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 drafts outreach from specific evidence and never sends messages. It distinguishes from sibling tools like talent_scout_create_packet or talent_scout_review_queue by focusing on drafting, not creating full packets or reviewing. The verb 'draft' is specific and the resource 'outreach' is clear.

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

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

The description mentions inputs like safe pains and voice evidence, giving context for when to use it. However, it does not explicitly state when not to use it or provide alternatives among the many sibling tools. The guidance is implied but not comprehensive.

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

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

Annotations already indicate readOnlyHint=true, and description adds valuable context: uses wallet SSoT status, verifies before recommending, never sends, requires human approval. These details disclose important behavioral traits beyond what annotations provide, with no contradictions.

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

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

Two sentences that are front-loaded with the core purpose, followed by key behavioral details. No unnecessary words or repetition. Efficiently communicates essential 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?

Despite having an output schema, the description omits details about the return structure. It adequately covers behavioral context but not parameter semantics. Given the tool's complexity (12 parameters, diverse routing modes), the description is incomplete for an agent to use it without 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 only 33%, and the description provides no information about any of the 12 parameters. Many parameter names are self-explanatory, but several (e.g., sqlite_path, auth_token_key, tenant_database_type) require more context for correct usage. The description fails to compensate for the low schema coverage.

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

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

Description clearly states it prepares business email enrichment receipts for a qualified contact, specifying 'Hunter.io-style' which distinguishes it from other talent_scout tools that involve searching or composing. It also mentions key behaviors like verification and no sending, making the purpose distinct and 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?

Description implicitly guides usage by stating 'never sends' and 'requires human approval', suggesting this is a preparatory step before outreach. However, it lacks explicit when-to-use or when-not-to-use guidance and does not mention alternatives among siblings.

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

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

Annotations already declare readOnlyHint=true. The description adds safety constraints beyond annotations (no scraping, auto-connect, auto-message) and emphasizes human review, providing useful behavioral context 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?

Two sentences, zero wasted words, front-loaded with the core action – highly concise and well-structured.

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

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

Despite an output schema existing, the description is too brief for a tool with 10 parameters. It omits how parameters affect behavior, preconditions (e.g., company qualification), and expected output structure, making it incomplete for effective agent use.

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 only 40% schema description coverage and no parameter details in the description, the tool fails to add meaning beyond the schema. The description does not explain key parameters like company_name, role_lane, or tenant_id, leaving agents underinformed.

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 generates safe likely-contact labels and LinkedIn search queries for a qualified company, using specific verbs and distinguishing it from sibling tools that perform direct outreach or enrichment.

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 warns against automated actions (no scraping, auto-connect, auto-message) and mandates human review, but does not explicitly contrast with alternative tools like talent_scout_enrich_contact_email or provide specific when-to-use guidance.

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

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

The description states it imports data into the cloud queue, implying state mutation, but the readOnlyHint annotation is true, which suggests no state changes. This is a direct contradiction. Additionally, the description provides limited behavioral context beyond the 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?

Two concise sentences front-load the core purpose and add clarifying behavioral constraints with 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?

With 11 parameters (0 required), no description of fields, and an output schema not provided, the description is insufficient for an agent to use this tool correctly. It needs more detail on parameter usage and expected input structure.

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

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

Schema description coverage is 0%. The description provides no information about the 11 parameters, many of which are complex objects with additionalProperties. Without any parameter guidance, the agent cannot understand how to structure input.

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 imports a guarded BYOC-local Talent Scout queue delta into the cloud queue, specifying it is closed-world queue bookkeeping only and never auto-applies/sends/clicks. This differentiates it from sibling tools like talent_scout_compose_application or talent_scout_draft_outreach.

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 syncing delta without automatic actions, but it does not explicitly state when not to use it or mention alternatives among the 50+ sibling tools. The context is clear but lacks exclusions.

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

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

Annotations already declare readOnlyHint, destructiveHint, and idempotentHint. The description adds valuable behavioral context: it never calls a client Gmail connector, never returns raw mail bodies, and fails softly with mailbox_reconciliation_status instead of a bare 502. This goes beyond annotations and discloses important safety and error-handling details.

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

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

The description is a single, well-structured sentence that front-loads the core purpose. Every clause adds value: purpose, alternative context, exclusions, and error handling. It could be slightly more concise but is effective and informative.

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

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

The description covers the tool's purpose, behavioral traits, and usage context quite well. Since an output schema exists, return values need not be detailed. However, the complete omission of parameter information is a notable gap, especially given the tool's moderate complexity. The description is adequate but not fully complete.

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

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

Schema description coverage is 0%, so the description must compensate. It does not mention the 'limit' or 'tenant_id' parameters, leaving their purpose and constraints unexplained. The agent cannot infer how to use them effectively from the description alone.

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

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

The description clearly states it reads Talent Scout mail-signal status from a server-side Gmail reconciliation path, distinguishing it from the local BYOC alternative and from the review_queue sibling tool. It uses the specific verb 'Read' and identifies the resource as 'mail-signal status'.

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

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

The description provides explicit usage context: it is the reliable replacement for the local BYOC scout.mail_signals when the cleverq.net/local tunnel is down. It also clarifies what it does not do (calling client connector, returning raw mail bodies) and its failure behavior. However, it does not explicitly list alternative tools 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.