StackFast FractWin Expert Brain

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

Annotations already indicate readOnly, idempotent, and non-destructive. The description adds behavioral context that it is review-only and does not communicate autonomously, which goes beyond the annotations and assures users of no side effects.

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

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

Two sentences: the first states the action, the second clarifies limitations. No redundant or filler content, and the key information is 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?

For a simple read-only packet retrieval, the description covers the core purpose and non-actions. An output schema exists and annotations are rich, so the description is sufficient, though it could briefly differentiate from sibling tools like ai_receptionist_review_queue.

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

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

Schema description coverage is 0% and the description does not explain the parameters. 'call_id' and 'tenant_id' are left to the schema's minimal type info, so the description adds no semantic value beyond the field 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 clearly states 'Return a human-review callback packet for one AI Receptionist call' with a specific verb, resource, and scope. It also explicitly distinguishes from autonomous actions by stating it does not send SMS, place calls, or reply to customers.

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

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

The description provides clear context by stating the packet is 'review-only' and does not send/place/reply, which implies when to use it. However, it does not explicitly name alternative tools or exclusion criteria compared to sibling tools like the review queue.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false, and idempotentHint=true. The description adds valuable constraints beyond the annotations: it states that outputs are 'masked/audit-safe identifiers only' and that callback/A2P status appears 'where present.' This informs the agent about data redaction and conditional fields, which is not captured by 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 primary action ('List recent AI Receptionist call-loop receipts') and adds important qualifiers (for human review, masked/audit-safe identifiers, status inclusion). Every clause adds value without unnecessary verbosity.

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

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

Given the tool's simplicity (2 optional params, no required params) and the presence of annotations and an output schema (though its content is not provided here), the description covers the purpose, scope, and output constraints. The only notable gap is lack of parameter semantics, but the tool is otherwise well-contextualized for an AI agent.

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

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

Schema description coverage is 0%, so the description must compensate for the parameters. It does not mention 'limit' or 'tenant_id' at all, leaving their semantics to inference. Since the tool has only two optional parameters, failing to explain them is a notable gap, especially for 'tenant_id' which may have scoping implications.

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, specifying the resource (receipts), action (list), and scope (recent, call-loop, with callback and A2P-gated inbound SMS status). This distinguishes it from sibling tools like ai_receptionist_callback_packet (likely fetches a specific packet) and ai_receptionist_status (likely checks 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 gives clear context ('for human review') and scope (recent receipts, including status where present), implying use when a human needs to review call-loop receipts. It does not explicitly name alternatives or say when not to use it, but the purpose is clear enough to guide selection among the sibling tools.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint false. The description adds that it returns 'masked/status metadata only', which is extra behavioral context about the output not present in annotations. It also clarifies the per-call scoping, which supplements 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 a single, well-structured sentence that front-loads the verb and resource list. It conveys all necessary information without 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?

With an output schema present, the description sufficiently explains the scope and return type ('masked/status metadata only'). It lacks clarification on the optional tenant_id parameter, but the core functionality is complete for a read-only status tool.

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

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

The description gives meaning to the required parameter call_id by stating the operation is 'for one AI Receptionist call ID'. However, the optional tenant_id parameter is not mentioned at all, and schema description coverage is 0%, so the description only partially compensates for the missing schema descriptions.

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

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

The description uses the specific verb 'Read' and enumerates exactly what data is retrieved: Desk ticket, CRM callback task, call-link receipt, and A2P-gated inbound SMS posture. It clearly scopes the action to a single AI Receptionist call ID, distinguishing it from sibling tools like ai_receptionist_callback_packet and ai_receptionist_review_queue.

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

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

The description implies when to use it: when you need the combined status of ticket, callback task, call-link receipt, and inbound SMS posture for a specific call ID. It doesn't explicitly mention alternatives or exclusions, but the context is clear and the tool's role as a status reader is evident.

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

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

The readOnlyHint annotation already declares safety, and the description adds valuable context by listing exactly what is read (provenance, findings, statuses, receipts) and the single-artifact scope. No contradiction with annotations found.

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

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

The description is a single, well-structured sentence that front-loads the action 'Read' and efficiently lists all audit categories. No wasted words.

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

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

The output schema and readOnlyHint reduce some burden, and the description covers the core purpose and data categories. However, parameter semantics are missing, and there is no guidance on when to prefer this over sibling audit/export tools, leaving the description only partially complete for 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%, so the description carries the burden but only mentions 'tenant-scoped artifact' without explaining how draft_id, artifact_id, and tenant_id relate. The agent cannot distinguish which identifier to provide for a given artifact audit 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 the tool reads a specific resource ('one tenant-scoped artifact') and enumerates the exact data categories (provenance, analyzer findings, gate status, approval state, usage, export receipts). This distinguishes it from sibling tools like artifact_export (which exports) or artifact_save (which mutates).

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 read-only artifact auditing but does not explicitly state when to choose it over alternatives such as audit_status or artifact_export. No exclusions or alternative context are provided, though the 'tenant-scoped artifact' phrase clarifies the target scope.

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

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

Annotations declare readOnlyHint=true, and the description does not contradict that, though 'Create' could be ambiguous. It adds useful context about approval and external-publish separation, but it doesn't disclose any side effects, permission requirements, or audit behavior beyond what the annotation implies.

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

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

The description is two sentences, front-loaded with the primary purpose, and every sentence adds meaningful context. No fluff or redundancy.

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

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

Given the tool's complexity (8 parameters, nested objects, output schema), the description lacks enough guidance for an agent to correctly construct calls. It omits how to choose between artifact_id and draft_id, what target options are valid, and how approval is indicated, leaving the agent reliant on the schema alone.

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 explanation of parameters such as tenant_id, target, format, artifact_id, or draft_id. With 8 parameters including enums, this is a critical gap that the description fails to address.

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

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

The description uses a specific verb and object ('Create an audited export receipt') and clearly scopes it to 'an approved artifact or internal draft.' It also distinguishes from external publishing, which sets it apart from sibling tools.

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

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

The description states the tool is for approved artifacts or internal drafts and explicitly notes that external publish is separate and human-approved. This provides clear context for when to use it, though it doesn't name an alternative tool.

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

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

The description adds substantial behavioral context beyond the readOnlyHint annotation: it mentions no-fabrication placeholders, analyzer provenance, MASK, brand status, and approval requirements. This tells the agent what to expect from the output and internal governance. There is no contradiction with annotations; 'Generate a draft' is consistent with readOnlyHint since it likely does not persist.

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

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

The description is a single, front-loaded sentence that efficiently communicates the core purpose and key constraints. However, it is dense with jargon such as 'MASK' and 'analyzer provenance' that may obscure meaning, preventing a perfect score.

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

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

Given the high complexity (17 parameters, enums, nested objects) and zero schema property descriptions, the tool description is too minimal. It does not clarify how to configure the various artifact types, tones, or output formats, nor does it explain the significance of the approval requirements. The presence of an output schema helps but does not compensate for the lack of usage context.

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

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

Schema description coverage is 0%, so the description must compensate, but it only vaguely hints at parameters via 'tenant-scoped' (tenant_id) and 'artifact draft' (artifact_type). It does not explain lane, format, locale, audience, variant_count, source_context, or other key parameters despite 17 parameters being present.

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

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

The description opens with a specific verb and resource: 'Generate a governed, tenant-scoped artifact draft.' It clearly distinguishes this from siblings like artifact_save and artifact_refine by emphasizing 'draft' and listing distinct features (no-fabrication placeholders, analyzer provenance, MASK, brand status, approval requirements).

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 is given for when to use this tool versus siblings like artifact_refine or artifact_save. The word 'Generate' implies initial creation, but there is no stated alternative, prerequisite, or exclusion to help an agent choose correctly among the many sibling artifact 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 description says 'Refine an existing artifact draft', which implies a mutating write operation, but the annotations declare readOnlyHint=true. This is a direct contradiction. The description also mentions preserving certain properties, but this does not resolve the fundamental conflict, so the score is 1 and annotation_contradiction is true.

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

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

The description is a single, tightly written sentence that front-loads the core action and key constraints. No wasted words 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?

Although an output schema exists, the tool has 11 parameters and the description provides only a high-level action with no detail on the refinement process, required inputs, or behavior. The annotation contradiction further undermines completeness, leaving important gaps for the agent to navigate.

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

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

The schema description coverage is 0%, so the description must compensate by explaining parameters. It does not mention any of the 11 parameters or how they relate to refinement. While schema names like 'refinement_instruction' and 'draft_id' are somewhat self-explanatory, the description adds no value beyond the schema, leaving many parameters unexplained.

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

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

The description clearly states the tool refines an existing artifact draft, using a specific verb and resource. It also distinguishes from sibling tools like artifact_generate (create new) and artifact_save (save), making the purpose unambiguous.

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

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

The phrase 'existing artifact draft' implies the tool is for refining already-created drafts, which indirectly contrasts with generating new ones. However, it does not explicitly name alternative tools or state when not to use this tool, so guidance is implied rather than explicit.

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

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

Annotation Contradiction: The annotations declare readOnlyHint=true, but the description says 'Approve/save' and 'mark eligibility,' which clearly imply state-changing/write behavior. The description contradicts the annotation and provides no clarifying context.

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

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

The description is two concise sentences, front-loaded with the action and resource, and includes a useful scope qualifier ('Does not publish externally'). 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?

While an output schema exists, the tool has 7 parameters with no schema descriptions, and the annotation contradicts the description. The brief description leaves significant gaps about parameters and behavioral expectations, making it incomplete for a mutating tool.

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

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

Schema description coverage is 0%, and the description does not explain any of the 7 parameters. Terms like 'tenant-scoped' hint at tenant_id and 'learning-loop eligibility' at learning_scope, but approved, reuse_tags, idempotency_key, and approval_event_id remain completely unexplained.

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 approves/saves an artifact and marks learning-loop eligibility, distinguishing it from artifact_audit, artifact_export, artifact_generate, and artifact_refine. The combined 'Approve/save' action is slightly ambiguous but still conveys the core resource and verb.

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

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

No explicit guidance on when to use this tool versus alternatives. The description only states what it does, not when to choose it over sibling artifact tools. Context is implied but no exclusions or alternative references are given.

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

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

The readOnlyHint annotation already establishes that this is a safe read operation. The description adds context by enumerating the specific data categories accessed (deliverable refs, credit ledger, Desk/CRM links), providing useful behavioral context beyond the annotation without contradicting it.

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

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

The description is a single sentence, front-loaded with the verb 'Read,' and every word earns its place by listing the specific resources. No filler or redundant 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?

The description covers the core purpose and data scope, but with two parameters and no schema descriptions, the lack of parameter context makes it incomplete for an agent to invoke correctly. The presence of an output schema reduces the need to describe return values, but usage context remains thin.

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 parameter meaning, but it does not mention tenant_id or audit_project_id at all. The tool name hints that audit_project_id identifies the audit, but this is not explicit, and tenant_id is completely unexplained, leaving a significant gap for 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 uses the specific verb 'Read' and clearly identifies the resource: 'AI Stack Audit project state,' further detailing deliverable refs, credit ledger, and Desk/CRM links. This distinguishes it from sibling tools like artifact_audit or boot_status, which address different audit or status concerns.

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 one needs to inspect audit project state, but it provides no explicit when-to-use vs. alternatives or exclusion criteria. Given the presence of many sibling tools, more explicit guidance would help, but the implied context is clear enough.

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

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

Annotations already declare readOnlyHint=true and idempotentHint=true, so the read-only behavior is covered. The description adds a valuable safety guarantee—'Does not expose secrets'—which is beyond the structured annotations and reassures the agent about sensitive data handling.

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

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

A single sentence with no wasted words. It front-loads the core purpose ('Read-only StackFast connector health/status check') and adds a brief safety note, making it 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?

Given the low complexity (one optional parameter, output schema present, rich annotations), the description covers the essential purpose and safety characteristics. The only minor gap is a slightly more explicit statement of what 'health/status' includes, but the output schema covers return details.

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

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

The input schema covers 100% of the single optional parameter 'role' with a clear description. The tool description does not add any parameter-level information beyond the schema, so the baseline score of 3 applies.

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

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

Description clearly states it is a read-only health/status check for StackFast connector, using a specific verb+resource. This distinguishes it from sibling status tools like ai_receptionist_status or audit_status by naming the exact target (StackFast connector).

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 it is a health/status check, which gives context for when an agent might use it (e.g., verifying connector readiness). However, it does not explicitly state when to use it vs alternatives or provide exclusions, leaving room for ambiguity among the many sibling status-related tools.

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

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

Beyond the readOnlyHint annotation, the description discloses that no secret values are exposed, and details the exact return categories (service slugs, env/key aliases, categories, resolver guidance). This adds meaningful behavioral context about the tool's non-sensitive output.

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

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

The description is three sentences, each serving a distinct purpose: stating the core capability, specifying when to use, and enumerating outputs. No waste, front-loaded with purpose and key safety constraint.

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

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

For a low-complexity tool with one optional parameter and an output schema, the description fully sets expectations: what it returns, what it never returns, and the canonical use cases. It is complete enough for an agent to select and invoke correctly without further clarification.

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

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

The single query parameter is fully documented in the input schema with examples, achieving 100% schema_description_coverage. The tool description adds no additional parameter semantic value, so the baseline score of 3 is appropriate.

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

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

The description opens with a specific verb and resource: 'Discover wallet-resolved credential service names and accepted aliases'. It clearly distinguishes from any sibling tool by focusing on credential discovery without secret exposure, and clarifies it returns only metadata and resolver guidance.

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

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

It explicitly states when to use the tool: 'when an agent is unsure whether a key exists, sees a key-not-found error, or needs the canonical getAgentKey(service) name'. It also provides an implicit exclusion by stating it 'never returns raw credentials', guiding agents away from using it for secret retrieval.

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 the tool as read-only, idempotent, and non-destructive. The description adds some useful context (tenant-scoped, StackFast storefront catalog, generic estimator_* control-plane contract), but it does not disclose search behavior, filtering semantics, or result handling beyond those 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 is not effectively concise; it uses vague, jargon-heavy phrasing ('generic estimator_* control-plane contract') and fails to deliver concrete information. The sentence is under-specified rather than tightly written.

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

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

For a search tool with 13 parameters, nested objects, and an output schema, the description is severely incomplete. It does not explain what the search returns, how query or line inputs are used, what the output schema contains, or how it relates to other catalog tools. The output schema exists but cannot carry the burden of explaining search semantics.

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% (only tenant_id and adapter_id have descriptions), yet the description adds no parameter-specific meaning. It mentions 'tenant-scoped' which loosely maps to tenant_id, but query, line(s), bridge, format, approval, source_id, document_id, estimate_id, and other parameters are left entirely unexplained. The description does not 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?

The description uses the vague verb 'Operate on' rather than a specific action like 'search' or 'query', even though the tool name and title clearly indicate a search function. It names the resource (tenant-scoped OCE Estimator catalog sources/items) and mentions StackFast, but does not distinguish this tool from the sibling estimator_catalog_sources.

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

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

No guidance is provided about when to use this tool versus alternatives. It does not mention the sibling estimator_catalog_sources or other estimator_* tools, and there is no when-not-to-use or prerequisite information.

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

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

The description adds no behavioral information beyond what the annotations already provide. Annotations declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, but the description does not explain the 'generic estimator_* control-plane contract' or any operational details like pagination, scoping, 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?

The description is a single sentence, which is concise, but it sacrifices substance for brevity. The phrase 'operate on' is a vague placeholder and the sentence is not front-loaded with an actionable verb, so it does not earn its place.

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

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

With 13 parameters, a complex resource, and many sibling tools, this description is severely under-specified. It gives no indication of the core operation, how it relates to the estimator_* family, or what specific action the agent should invoke it for, making it inadequate for correct selection and invocation.

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

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

Schema coverage is only 15%, with only tenant_id and adapter_id having descriptions. The tool description gives a slight hint about tenant scoping but does not explain the purpose or expected format of source_id, document_id, query, or the other nine parameters. It 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?

The description uses the vague verb 'operate on' and never specifies whether the tool lists, retrieves, creates, or updates catalog sources. It names the resource (catalog sources/items) but does not distinguish it from sibling tools like estimator_catalog_search, making the tool's purpose ambiguous.

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

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

The description provides no guidance on when to use this tool versus alternatives. It does not mention any conditions, prerequisites, or exclusion cases, leaving the agent to infer usage solely from the tool name and annotations.

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

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

The description adds no behavioral context beyond the annotations. It does not disclose side effects, permissions, or the fact that the tool is expected to add a line (despite the name). The readOnlyHint:true annotation conflicts with the tool's name 'add_line', creating ambiguity that the description fails to resolve.

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, making it concise, but it is under-specified and lacks front-loaded key information. While no words are wasted, the brevity is not an advantage because it fails to convey 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?

For a tool with 13 optional parameters, nested objects, and an output schema, the description is severely incomplete. It omits the operation's purpose, parameter relationships, and use cases, leaving the agent without enough context 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?

With schema description coverage at 15%, the description was expected to compensate for undocumented parameters, but it does not mention any parameters. The schema only barely describes tenant_id and adapter_id, and the description offers zero additional meaning for 'line', 'lines', 'bridge', or other fields.

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

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

The description uses the generic verb 'Operate' and lists a broad set of resources (drafts, lines, versions, documents, exports, policy receipts) without specifying the tool's actual action of adding a line. It does not clearly state what the tool does, nor does it distinguish itself from sibling tools like estimator_estimate_update_line or estimator_estimate_export.

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

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

No guidance is provided on when to use this tool versus alternatives. The description only mentions 'tenant-scoped' context, which is too vague to inform selection. It neither states prerequisites nor excludes cases where other tools should be used.

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, destructiveHint=false, idempotentHint=true, but the description adds no behavioral context. It does not explain what conversion means, what happens to the estimate, or any side effects. The description is scope-only, not 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 sentence but is over-broad and under-informative. It packs many nouns into a generic phrase that does not earn its place; brevity here sacrifices essential meaning.

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

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

Despite having 13 parameters, nested objects, an output schema, and sibling tools that offer differentiation, the description provides almost no usable context. It fails to explain the tool's purpose, inputs, workflow, or outputs, making it nearly useless for selection and invocation.

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

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

Schema description coverage is only 15% (2 of 13 parameters described). The description does not compensate by tying the listed entities (drafts, lines, versions, etc.) to specific parameters, leaving most parameters completely undefined for the agent.

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 vague verb 'operate on' and lists multiple entity types but never states the core action of converting an estimate to a bid. It does not distinguish this tool from obvious siblings like estimator_estimate_convert_to_invoice or estimator_estimate_export.

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

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

There is no guidance on when to use this tool instead of alternatives. The description does not mention the conversion workflow, prerequisites, or any exclusion criteria, leaving the agent to guess based on the tool name.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds useful context: 'Review-gated' and 'does not write to accounting systems,' which clarifies the operational flow and reinforces the read-only, non-destructive nature. This goes slightly beyond the structured 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 a single concise sentence with no filler. It is front-loaded with the core purpose. However, its brevity sacrifices necessary detail, making it less helpful for a complex tool.

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

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

Despite having an output schema and annotations, the tool is complex (13 params, nested objects) and the description is too sparse. It does not explain what 'OCE Estimator/Appraiser document' or 'QBO handoff contract' entails, nor how the many parameters are used in the conversion process. This leaves 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?

The input schema has 13 parameters with only 15% description coverage (tenant_id and adapter_id). The description does not explain any of the other parameters (line, lines, query, bridge, approval, etc.) or how they relate to preparing the document/contract. With such low schema coverage, the description should compensate but does not.

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 an OCE Estimator/Appraiser document or QBO handoff contract') that aligns with the tool's name and title. It clearly indicates the tool produces a prepared document/contract. However, it does not explicitly differentiate from the sibling tool estimator_estimate_convert_to_bid, though the name itself provides that distinction.

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

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

The description implies usage context with 'Review-gated; does not write to accounting systems,' signaling this is a safe, read-only preparation step. But it lacks explicit when-to-use or when-not-to-use guidance relative to alternatives like convert_to_bid or progress_invoice. The user must infer when to select 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?

The description adds no behavioral detail beyond the annotations. More seriously, it contradicts the annotations: the tool name 'create_draft' implies a write operation, but annotations declare readOnlyHint=true. This is an annotation contradiction, and the description does nothing to clarify the actual side effects or safety profile.

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

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

The description is a single short sentence, but it is under-specified and does not convey meaningful information. It is vague and generic, earning a low score for ineffective conciseness because it wastes the opportunity to provide 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?

With 13 parameters, no required fields, and an output schema that is not described, the description is completely inadequate. It does not explain the tool's purpose, behavior, or parameter usage, leaving the agent without enough context 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% (only tenant_id and adapter_id have descriptions). The description does not compensate; it merely lists entity types without mapping them to the 13 parameters. No parameter meaning or relationships are explained beyond what the sparse schema already provides.

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

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

The description uses the vague verb phrase 'Operate on' rather than specifying a concrete action like 'create' or 'draft'. While the title suggests 'create draft', the description lists multiple entity types (drafts, lines, versions, documents, exports, policy receipts) without explaining what operation is performed on them. It fails to distinguish this tool from siblings like estimator_estimate_add_line or estimator_estimate_update_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 is provided on when to use this tool versus alternatives. The description does not mention any context, prerequisites, or exclusions. Given the abundance of sibling estimator tools, this absence is critical.

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, but the description adds only tenant-scoping and domain context. 'Operate on' is ambiguous and doesn't clarify whether this is a read/export operation or something else. There's no disclosure about return formats, pagination, or side effects. The description doesn't contradict the annotations but fails to add meaningful behavioral context.

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

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

The description is a single sentence, so it is concise in length, but it lacks substance. It is not front-loaded with the primary action (export) and doesn't earn its place because it provides no operational detail. Conciseness without content is not a positive.

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

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

For a tool with 13 parameters, nested objects, enums, and an output schema, the description is severely incomplete. It doesn't clarify the core operation, parameter relationships, or typical usage. Even with an output schema present, the tool's purpose is ambiguous, making it difficult to invoke correctly.

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

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

Schema description coverage is only 15% (tenant_id and adapter_id). The description doesn't explain any of the 13 parameters, nor does it map the listed resource types to parameters like document_id, estimate_id, or lines. With such low schema coverage, the description should compensate but doesn't.

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 vague verb 'Operate on' and lists resource types (drafts, lines, versions, documents, exports, policy receipts) without stating the actual action. The title says 'estimate export' but the description never mentions exporting, and it doesn't distinguish this tool from sibling estimator tools like estimator_estimate_create_draft or 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 is provided on when to use this tool versus alternatives. It doesn't mention export scenarios, prerequisites, or exclusions. With many estimator-related siblings, the lack of differentiation makes the tool impossible to select correctly.

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, and destructiveHint=false. The description adds the useful context of being 'Review-gated' and not writing to accounting systems, which goes beyond the annotations and clarifies the tool's non-mutating, preparation-only behavior. No contradiction exists.

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

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

The description is a single, compact sentence that front-loads the action and includes essential caveats (review-gated, no writes). Every word earns its place, with no redundancy or filler.

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

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

This is a complex tool with 13 parameters (many nested objects) and an output schema, yet the description provides only a two-part overview. It leaves the agent guessing about what inputs matter, what the 'OCE Estimator/Appraiser document' is, and how this relates to progress invoices. The description is too thin for the tool's 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?

With schema description coverage at only 15%, the description carries a heavy burden to explain parameters, but it mentions none of the 13 parameters. The description adds no meaning to the ambiguous fields like line, bridge, or approval, so it 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?

The description uses the verb 'Prepare' with a clear resource ('OCE Estimator/Appraiser document or QBO handoff contract'), which gives a specific action. However, it does not explicitly mention 'progress invoice' or differentiate from siblings like estimator_estimate_export or estimator_estimate_convert_to_invoice, so it is clear but not fully distinguished.

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

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

The phrase 'Review-gated; does not write to accounting systems' implies a safe, preparation-only context, which helps an agent decide when to use it. But it doesn't explicitly state when to use this tool versus alternatives, nor does it name any exclude cases, so guidance is only implied.

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

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

Annotations already declare readOnlyHint=true and idempotentHint=true, so the description adds little behavioral context. It says 'Operate on' which is ambiguous about read vs. write, and it does not disclose any side effects, prerequisites, or return behavior. No contradiction, 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 is not concise in a meaningful way; it is under-specified and reads like a generic catch-all. It names many resources without explaining the tool's specific function, so it is vague rather than 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?

For a tool with 13 parameters, nested objects, an output schema, and many sibling tools, this description is completely inadequate. It does not explain what the tool does, when to use it, or how 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% (only tenant_id and adapter_id have descriptions). The description itself does not explain any parameters, leaving the 13 parameters, including nested objects and enums, completely unexplained.

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 tenant-scoped OCE Estimator/Appraiser drafts, lines, versions, documents, exports, and policy receipts.' This is vague and does not specify that the tool updates a line in an estimate, which is what the name suggests. It does not distinguish this tool from siblings like estimator_estimate_add_line or estimator_estimate_export.

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

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

There is no guidance on when to use this tool versus alternatives. The description merely lists resource types, with no mention of specific scenarios, prerequisites, or exclusions.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is known. However, the description adds no behavioral context about what the policy check does, what 'policy receipts' are, or what outcomes to expect.

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

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

The single sentence is short but imprecise. It wastes the opportunity to state the core action and instead lists generic resource categories, lacking front-loaded, useful 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 the tool's complexity (13 params, nested objects, output schema) and low schema coverage, the description is far too thin. It does not explain what a policy check involves, what inputs drive it, or what the output report contains.

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 provides no parameter-level meaning beyond listing resource types. It never mentions tenant_id, adapter_id, or any of the 13 parameters, failing to compensate for the sparse schema.

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

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

The description uses the vague verb 'Operate' and lists resource types but never states the specific action (e.g., 'check policy compliance'). It does not mention 'policy check' or differentiate from the many sibling estimator_* 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?

There is no guidance on when to use this tool versus alternatives, no prerequisites, and no exclusionary context. A zero-required-parameter schema with 13 optional parameters makes this especially confusing.

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, but the description adds no meaningful behavioral context beyond listing resource types. The word 'Operate' is vague and does not clarify that this is a read/get operation, nor does it describe response behavior or any constraints beyond the tenant scoping shown in the schema.

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

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

The description is a single sentence but is under-specified and full of vague terms. It spends its length listing entity types without conveying the tool's core purpose, making it neither concise nor well-structured for agent 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?

For a tool with 13 parameters, no required fields, nested objects, and an output schema, this description is completely inadequate. It fails to explain what the tool does, what fields mean, or how to invoke it properly, leaving the agent with almost no usable 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 15% (tenant_id and adapter_id), and the description offers no explanation of the other 11 parameters such as line, query, bridge, format, approval, source_id, document_id, estimate_id, progress_pct, and idempotency_key. The description does not 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?

The description uses the generic verb 'Operate' and lists many entity types (drafts, lines, versions, exports, receipts) without specifying the action. The tool name implies 'get receipt', but the description does not state that it retrieves a receipt, making it ambiguous and not distinct from sibling tools like estimator_estimate_export or estimator_catalog_search.

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

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

No guidance is provided on when to use this tool versus the many estimator_* siblings. There are no scenarios, exclusions, or alternative tool references, leaving the agent without direction on selection.

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

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

The description adds pagination behavior (the next_page loop) beyond what the annotations provide. With readOnlyHint and idempotentHint already marking the tool as a safe, idempotent read, the description's clarification of the pagination pattern is valuable. No contradiction with annotations.

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

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

The description is two sentences, with the primary purpose in the first sentence and a usage example in the second. It is front-loaded and contains no filler, with every part earning its place.

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

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

The description fully covers the pagination workflow, which is the only nontrivial aspect for a read-only fetch tool. Since an output schema exists, return values need no additional explanation. The tool is contextually complete for its intended 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?

Schema description coverage is 100%, so the baseline is 3, but the description adds practical meaning: it gives a concrete example showing how to use id, page, and page_size, and clarifies that id is returned by the search tool. It also reinforces the next_page alias and explicit page_size bounds.

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 fetches a StackFast Brain search result by id using the AI6 MCP reader plane. The specific verb 'fetch' and resource are explicit, and the focus on retrieving by id distinguishes it from the sibling 'search' tool.

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

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

The description provides a concrete usage example with id, page, and page_size, and instructs to continue with next_page until complete is true. It implies the tool is used after a search to retrieve a specific result, though it does not explicitly name alternatives or exclusions.

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

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

The description states 'Start or append,' which implies write operations, directly contradicting the annotation readOnlyHint: true. This is a severe inconsistency. The additional note about 'Outputs remain draft_review_required' is useful behavioural context but cannot outweigh 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?

The description is efficiently concise, using two short sentences to convey the core action and output status. It is front-loaded and free of fluff, but the brevity compromises necessary detail, slightly lowering the score.

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

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

Given the tool's complexity (11 parameters, 2 enums, output schema) and the contradiction with annotations, the description is severely incomplete. It fails to explain the action enum, interview types, session model, or relationship to sibling tools. The output schema exists but the description doesn't bridge the gap for selecting and invoking 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?

With 11 parameters and 0% schema description coverage, the description adds no meaningful parameter semantics. It does not explain key parameters like action, answers, session_id, or interview_type. The phrase 'existing interview/session model' is too vague to compensate for the complete lack of parameter 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 clearly states a specific action ('Start or append') and resource ('GrowthOS Business Brain Interview'), making the tool's purpose evident. However, it does not explicitly differentiate from sibling GrowthOS tools like growthos_scorecard or growthos_digital_clone_packet, relying mainly on the unique tool name for distinction.

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

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

The description provides no direct guidance on when to use this tool versus alternatives. It implies use for starting or appending to an interview but does not mention prerequisites, exclusions, or specific scenarios. The note about 'Outputs remain draft_review_required' hints at a workflow consideration but is not explicit about tool 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 mark this as read-only and idempotent, so the description needs only to add behavioral context. It adds meaningful guardrails by declaring 'No Robert voice defaults and no autonomous outbound,' which prevents misuse of the generated packet. It does not contradict the annotations, and avoids describing side effects beyond the draft-building 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 entire description is a single, front-loaded sentence that names the action, resource, input sources, and two critical constraints with no filler. Every clause contributes meaning, making it exceptionally concise.

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

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

The tool has a rich context envelope: full schema descriptions, output schema, and annotations. The description covers the essential purpose and non-behavioral constraints, while the schema fills in parameter details and return behavior. The main gap is explaining the 'PERSPECTIVE capability grounding' concept, but this does not prevent an agent from selecting or invoking the tool correctly.

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

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

Schema coverage is 100%, so the schema documents all three parameters (prospect, tenant_profile, perspective_context). The description partially reinforces these by mentioning 'runtime tenant voice profile' and 'PERSPECTIVE capability grounding,' but it does not add substantive parameter-level detail beyond the schema. Baseline 3 is appropriate.

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

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

Description opens with the specific verb 'Build' and identifies the unique resource 'draft GrowthOS digital-clone render packet,' immediately distinguishing it from sibling packet tools like growthos_opportunity_scout_packet. It enumerates the required inputs (normalized signals, evidence, tenant voice profile, PERSPECTIVE grounding) and states guardrails, leaving no ambiguity about the tool's function.

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

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

The description establishes clear usage context by stating that the tool builds a draft packet from normalized signals and evidence, and that a tenant_profile is required before publication (with draft_review_required fallback in the schema). It does not explicitly name alternative tools or say when not to use it, but the input prerequisites and 'no autonomous outbound' guardrail imply the intended use case.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds valuable context by noting it uses the existing gate-first policy layer and creates no new persistence table, reinforcing the read-only, non-persistent nature.

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 conveys all essential information without redundancy. It is front-loaded with the verb and resource, making it easy for an agent to parse.

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

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

The description effectively covers purpose, usage context, and persistence behavior, and an output schema exists for return values. The only minor gap is the lack of elaboration on the 'gate-first policy layer' semantics, but this is not critical given the tool's simplicity.

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

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

The description adds meaning beyond the schema by enumerating the opportunity types (customer, talent, contract, capital) that the opportunity object's opportunity_type must match. This compensates for the schema's generic reference to 'registered Opportunity Scout types'.

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'), and lists the relevant opportunity categories (customer, talent, contract, capital). It distinguishes the tool from sibling packet builders by mentioning the gate-first policy layer and no new persistence table.

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

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

The description provides clear context for when to use the tool: for building an Opportunity Scout packet across four specified opportunity types. However, it does not explicitly exclude alternatives or mention when not to use it, so it falls short of a 5.

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

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

Annotations already mark this as read-only, idempotent, and non-destructive. The description adds valuable non-obvious context: 'No autonomous send' prevents misinterpretation of the email-ready output, and the optional CogentCast receipt composition is disclosed. No contradiction with annotations exists; the description enriches the safety and behavior profile.

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

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

The description is a single, tightly-packed sentence that front-loads the action and includes necessary caveats ('No autonomous send') and output formats. Every phrase earns its place with no redundancy or fluff.

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

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

With four parameters, nested objects, and an output schema, the description sufficiently covers purpose, output types, optional composition behavior, and the no-send constraint. It doesn't explain 'prospect' or 'sender,' but the output schema and context fill some gaps, making this fairly complete but not exhaustive.

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

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

Schema description coverage is 50%, and the description only clarifies the optional CogentCast-related parameters via 'optional CogentCast site-review receipt composition.' It does not add meaning for the required 'prospect' parameter or 'sender,' leaving these underspecified. Since coverage is low, the description should compensate further but only partially does.

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 the canonical GrowthOS scorecard into an owner-facing report with specific output formats (web, email-review-ready, PDF-ready). This distinguishes it from sibling tools like growthos_scorecard, which likely produces the scorecard itself, and other packet/report tools by focusing on the report rendering step.

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

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

The description implies use when you need a sendable owner-facing report derived from the GrowthOS scorecard. It provides a key exclusion with 'No autonomous send,' clarifying that this tool only prepares the report and does not send it. However, it does not explicitly name alternatives or when-not-to-use conditions, so it's not a full 5.

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

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

Annotations already indicate readOnlyHint=true, idempotentHint=true, and destructiveHint=false, and the description does not contradict these. The description adds valuable behavioral context beyond annotations, such as 'No autonomous outbound' and the fact that it consumes external CogentCast receipts rather than recreating logic, which helps set expectations for side effects and dependencies.

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 compact, with two sentences that efficiently convey the tool's output and key behavior. It front-loads the main purpose and then provides necessary context about CogentCast and outbound constraints, with zero 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?

Given the tool's complexity (nested objects, 4 parameters, output schema available), the description covers essential aspects: what is returned, the CogentCast integration, and the no-autonomous-outbound behavior. It could explain jargon like 'review-gated' or 'step 3' more, but the output schema and parameter descriptions fill some gaps, making it fairly 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 50%: cogentcast_site_review and include_cogentcast_site_review have descriptive texts, while sender and prospect lack explanations. The description mentions 'supplied local-business evidence' which hints at prospect but does not clarify sender or the relationship between parameters. It adds some meaning through the reference to CogentCast, but the incomplete coverage leaves gaps.

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

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

The description clearly states the tool's function: 'Return a GrowthOS revenue-capture packet' with specific components (scorecard, review-gated contact drafts, CogentCast site-review receipt composition, summary). It distinguishes itself from sibling tools by mentioning the unique CogentCast integration and 'No autonomous outbound', making the purpose specific and unambiguous.

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

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

The description provides clear context for when to use the tool: for supplied local-business evidence and to leverage CogentCast receipts rather than recreating website-review logic. It includes an explicit constraint 'No autonomous outbound', which helps avoid misuse, though it does not explicitly name alternative tools for comparison.

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 establish read-only and non-destructive behavior, and the description adds that MCP execution requires reader entitlement and that the tool returns only findings without sending outreach. This goes beyond the annotations by disclosing access requirements and a key behavioral boundary (no outreach), providing useful context for an agent.

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

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

The description is three sentences, each carrying distinct information: purpose, access condition, and behavioral boundary. It is front-loaded with the main action and contains no redundant phrasing.

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

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

With an output schema present and concise parameter descriptions, the tool description covers the core purpose, access requirement, and return behavior. It could more explicitly define what constitutes 'public business signals,' but the schema and output schema fill in structural details, making it sufficiently complete for a tool of this complexity.

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

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

The input schema already provides 100% coverage of parameter descriptions (sender, prospect, prospects), so the description adds little extra meaning about parameters. The description's mention of 'supplied public business signals' loosely maps to the prospect parameters but does not elaborate on format or constraints, 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 opens with 'Build a private GrowthOS Revenue Capture Scorecard from supplied public business signals,' clearly identifying the verb (build), resource (scorecard), and input source. It distinguishes from siblings by emphasizing it 'never sends outreach' and returns 'findings only,' which separates it from outreach-focused GrowthOS tools.

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

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

The description states that MCP execution requires reader entitlement, which is a prerequisite for use. It also clarifies that the tool 'never sends outreach,' providing a clear when-not signal. However, it does not explicitly name alternative sibling tools for comparison, so it stops short of full guidance.

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

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

Beyond the readOnlyHint annotation, the description explicitly states 'It never sends the message' and notes manual approval and an artifact audit trail, which are critical behavioral details for an agent. This is genuinely helpful context and aligns with annotations.

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

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

The description is a single, front-loaded sentence that packs in the essential information without waste. It clearly states the tool's purpose, key features, and critical non-sending behavior.

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

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

For a complex tool with 14 parameters and nested objects, the description covers the core safety behavior and output artifact, but it omits details about parameters and usage nuances. Since an output schema exists, return values don't need explanation, but the lack of parameter guidance prevents a 5.

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

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

With 0% schema description coverage, the description must compensate for the 14 parameters. It introduces domain concepts like do_not_say, safe_phrasing, and channel constraints, which hint at parameter usage, but it doesn't map them to specific fields or explain their formats. This partial compensation earns a 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 tool composes a 'relationship-safe correspondence decision packet' with specific features (do_not_say, safe_phrasing, channel constraints, manual approval, audit trail) and explicitly differentiates it from sending tools by stating 'It never sends the message.' This a specific verb+resource that distinguishes it from siblings.

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

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

It provides clear context for when to use the tool: for composing a safe, approval-required reply that doesn't send. However, it doesn't explicitly name alternatives like talent_scout_draft_outreach or state when not to use it, so it 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?

Beyond the read-only and non-destructive annotations, the description reveals key operational behavior: search returns result IDs that require a separate fetch call for full text. It also names the access plane, adding valuable context not present in 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 action and includes necessary operational guidance without filler. Every word contributes value.

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

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

For a low-complexity, read-only tool with an output schema available, the description sufficiently covers the workflow (search, receive ID, fetch full text). No additional return-value explanation is needed given the output schema, and annotations cover safety.

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

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

The input schema already fully documents the single 'query' parameter as a natural language search query (100% coverage). The description adds no additional semantic detail about the parameter, so the baseline score of 3 is appropriate.

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

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

The description uses a specific verb ('Search') with a clear resource ('StackFast Brain knowledge'), distinguishing it from sibling search tools by domain. It also mentions the access mechanism ('AI6 MCP reader plane'), making the purpose unambiguous.

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

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

The description clearly implies this is for searching StackFast Brain knowledge and provides a follow-up instruction to use fetch with the returned ID for full text. It lacks explicit when-not-to-use or alternative tool references, but the context is clear enough for most agents.

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

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

With readOnlyHint=true annotation already covering safety, the description adds behavioral context by disclosing that raw contents are intentionally excluded and that URLs are persistent. This goes beyond the annotation without contradicting it.

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

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

Two sentences, front-loaded with the core purpose, and the second sentence adds a crucial limitation. No waste, every word earns its place.

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

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

The description covers the high-level purpose and limitation, and an output schema exists to document return values. However, with all parameters optional and no required parameters, the description does not clarify what happens when no filters are provided (e.g., returns all artifacts?) or how the parameters combine. This ambiguity leaves the tool incomplete for a 4-parameter, 0-required tool, even with 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?

Schema description coverage is 0%, so the description must compensate for parameter meanings. It does not mention limit, filename, session_id, or artifact_id at all. The parameter names are somewhat self-explanatory, but the description adds no detail about how they filter or interact, leaving the user to guess 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 states a specific verb ('return') and resource ('session artifact metadata and persistent URLs'). It also distinguishes itself from likely siblings by explicitly noting that V1 omits raw artifact contents, clarifying this is a metadata/URL access tool rather than a content export.

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

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

The description provides clear context that this tool is for metadata and URLs, and the phrase 'V1 intentionally omits raw artifact contents' implies an exclusion: do not use this for raw contents. Though it doesn't name alternative tools explicitly, the context gives enough guidance for selection 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 declare readOnlyHint=true and destructiveHint=false; the description reinforces and extends this by stating 'Draft/review only; no sends or applications,' clarifying there are no external submission side effects. It also enumerates the internal workup components, giving the agent a clear picture of what will be produced without modifying state.

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

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

The description is a single long sentence with a very long list of deliverables, which is informative but structurally dense. It front-loads the purpose but would benefit from bullet points; still, the list is directly useful and not filler.

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

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

For a complex 13-parameter tool with an output schema and annotations, the description gives a thorough enumeration of the workup contents and the draft-only mode. It covers the critical behavioral constraint and the main outputs, making it complete enough for an agent to select and understand the tool without needing to see the output schema.

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

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

Schema description coverage is 69%, so the schema documents most parameters. The description adds context for how the workup is assembled (e.g., includes follow-up drafts and interview prep) which helps infer the boolean flags, but it does not explain 'notes' or the parameter precedence beyond what exists in the schema.

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

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

The description uses a specific verb 'Build' and identifies the resource 'one Talent Scout queue item', enumerating a full list of deliverables that distinguish it from sending/applying tools. It explicitly states the output is a draft-only packet, which differentiates it from siblings like compose_application or record_application.

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

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

The description clearly states what the tool does and the boundary 'Draft/review only; no sends or applications,' which tells the agent not to use this when a send/apply is needed. However, it does not explicitly name alternative tools for those actions, so some inference from sibling names is required.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds behavioral constraints beyond that: reserving specific field categories for the human and mandating per-field readback before reporting 'staged'. This gives meaningful insight into how the tool behaves 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?

The description is two sentences and front-loaded with the core purpose, then adds safety and verification constraints. Every clause earns its place; no filler or redundancy.

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

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

The tool has 8 parameters and nested objects, but the description gives only high-level behavior with no parameter documentation, so an agent may not fully know how to construct arguments. The presence of an output schema mitigates the need to describe return values, but the input side remains under-specified for a tool this complex.

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 carries the burden for explaining 8 parameters, but it only implicitly references a few (e.g., 'schema_receipt' as 'complete form schema', 'profile_values' as 'stored profile values', 'readbacks' as 'per-field readback'). It does not explain send, apply, submit, fields, or tenant_id, leaving significant ambiguity for an agent deciding how to populate 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 opens with a specific verb phrase 'Build or verify a keyboard-event ATS fill plan' and identifies the resource ('from a complete form schema'), clearly distinguishing this from sibling tools like talent_scout_form_schema_receipt (which likely only fetches schema) and talent_scout_record_application (which records applications). It precisely captures the tool's role.

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

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

The description provides clear usage context: it operates on a complete form schema, maps safe stored profile values, reserves eligibility/EEO/files/signature/submit for human handling, and requires per-field readback before staging. This implies when to use it (when planning an ATS fill) and when not (for human-only fields), though it does not name explicit alternative tools or exclusion scenarios.

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

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

The description adds behavioral context beyond the annotations: it reveals the tool 'never sends', 'verifies before recommending', and 'requires human approval'. ReadOnlyHint and destructiveHint are already provided, but the description clarifies the workflow and guardrails, which is valuable. 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 two concise sentences, front-loaded with the core purpose. Each sentence adds essential information—what it produces and key behavioral constraints. No wasted words, and the structure is easy to scan.

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

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

Given the tool's complexity (12 params, sparse schema, output schema present), the description covers the primary behaviors: preparation, verification, no sending, and human approval. It doesn't elaborate on the database routing modes or credential handling, but these are partially covered by schema descriptions. The output schema exists, so return values need no explanation.

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

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

Schema coverage is only 33%, so the description needed to compensate for the 12 parameters, but it doesn't explain key parameters like domain, first_name, or company_name. It references 'wallet SSoT status' which loosely relates to auth_token_key and database_url_key, but it fails to clarify the role of most inputs, making it hard for an agent to know what values to supply.

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

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

The description clearly states the tool's purpose with a specific verb ('Prepare'), resource ('business email enrichment receipts'), and target ('qualified contact'). It also distinguishes the tool from siblings by explicitly noting it 'never sends' and 'requires human approval', setting it apart from sending-oriented tools like 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 provides clear usage context: it is for preparing receipts for qualified contacts, uses wallet SSoT status, and involves human approval. It implies the tool is not for sending emails by stating 'never sends', which serves as an implicit exclusion, but it does not explicitly name alternative tools or provide when-not-to-use scenarios.

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

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

Beyond the annotations (readOnlyHint=true, destructiveHint=false), the description adds explicit behavioral context: 'draft-only', 'never sends, applies, screens people, ranks people, or makes hiring decisions', and repeats the non-screening/non-ranking constraint. This discloses the tool's safe, non-mutating nature and its boundaries in a way annotations alone do not fully specify.

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 front-loaded with the main purpose, but the final sentence 'This does not screen applicants, rank candidates, or make hiring decisions' is redundant with the previous sentence 'never sends, applies, screens people, ranks people, or makes hiring decisions'. The redundancy adds no new information and could be removed for 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?

For a complex tool with 22 parameters and no required ones, the description gives a solid orientation: it identifies supported artifact types, the source (queue item + JD evidence), and safety constraints. It does not document lookup aliases or fallback paths, but the parameter descriptions in the schema cover those details. Overall, the description is sufficiently complete for an agent to understand the tool's role.

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

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

The description adds meaning beyond the schema by enumerating allowed output_kind values and emphasizing that the draft is based on a 'real Talent Scout queue item' and 'JD evidence', which guides parameter selection (e.g., queue_item_id, job_description_text). With 73% schema description coverage, the description supplements but does not fully replace schema details; it is helpful but not exhaustive.

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

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

The description clearly states a specific verb ('Compose') and resource ('a draft-only first-party job-seeker application artifact') for the account owner from a real Talent Scout queue item using JD evidence. It enumerates supported artifact types (cover letter, form paste, application Q&A, telephone script, authority analysis) and differentiates from siblings by explicitly declaring what it never does (sends, applies, screens, ranks).

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

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

The description provides clear context for when to use the tool: compose draft-only application artifacts from Talent Scout queue items with JD evidence, and supports only the listed output kinds. It does not explicitly name alternative sibling tools or state 'use X instead', but the constraints ('never sends, applies...') imply boundaries. Lacks explicit exclusions but is clear enough.

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

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

Annotation contradiction: readOnlyHint is true, but the description says 'Append' — a write operation. This is a serious inconsistency. Even though the description adds useful details (immutability, no side effects), the contradiction undermines trust and violates the scoring rule.

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

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

Two sentences, front-loaded with the core action, and every clause earns its place. It is compact, readable, and free of fluff.

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

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

Given the tool's complexity (10 params, output schema, annotations), the description covers the core behavior, immutability, and exclusions. The output schema handles return values. However, the contradiction with readOnlyHint creates an incomplete and confusing picture, preventing a perfect score.

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

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

Schema description coverage is 80%, so the baseline is 3. The description highlights 'channel' and 'direction' as the corrected fields, but does not add meaningful semantics beyond the schema's existing parameter descriptions. It does not compensate for the two undocumented parameters (tenant_id, channel).

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

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

The description clearly states a specific verb ('Append') and resource ('immutable correction for the channel and direction of an existing Talent Scout Relationship Core receipt'). It distinguishes itself from the sibling 'talent_scout_record_relationship_activity' by focusing on corrections, and explicitly states what it does not do.

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 context is clear: use for correcting an existing receipt. It also lists exclusions ('never sends, applies, scrapes, or changes candidacy status'), which helps prevent misuse. However, it does not explicitly name alternative tools or provide when-not-to-use criteria beyond these exclusions.

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

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

The description says 'Create a draft-only packet,' which implies a write operation and state change, while annotations declare readOnlyHint: true. This is a direct contradiction that undermines trust in both the description and annotations. No other behavioral traits are disclosed beyond the approval note.

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

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

The description is two sentences, with the main action in the first sentence and a critical caveat in the second. It is front-loaded and every word contributes value, making it 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?

While the description captures the core purpose and the human approval constraint, it lacks parameter guidance and contradicts the readOnlyHint annotation. Given the 0% schema description coverage and the presence of an output schema, the description leaves significant gaps for an agent to correctly select and invoke the tool.

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

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

The description indirectly maps queue_item_id ('from an existing Talent Scout queue item') and hints at output_kind via 'application or opportunity,' but it does not explain notes, actor_id, tenant_id, or opportunity_mode. With 0% schema description coverage, the description only minimally compensates for the missing parameter meanings.

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. The verb 'create' is specific and the resource is precisely defined, distinguishing it from sibling tools that handle other aspects of the talent scout workflow.

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

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

The description provides clear context for when to use this tool—when you have an existing queue item and need to produce a draft packet. It also notes that human approval is required, which is an important usage condition, though it does not explicitly mention 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?

Discloses that mailbox reconciliation runs server-side via the StackFast service-account reader, a critical behavioral trait not available in the annotations. It adds a hard constraint ('Clients MUST NOT invoke their own Gmail/email connector') and a stop condition for non-ok mailbox status. This goes well beyond the readOnlyHint=true and destructiveHint=false annotations, and there is no contradiction.

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

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

The description is dense but each sentence carries essential operational constraints: server-side mailbox read, prohibition on client connectors, and a stop condition. It is front-loaded with the main purpose, though the first sentence is long with many report sections. No filler or redundancy beyond a brief final read-only note.

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

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

Given 11 parameters, nested objects, and an output schema, the description covers the report's content, server-side execution, client prohibitions, and error handling behavior. It omits details about tenant authorization or the full structure, but the output schema and parameter descriptions fill those gaps. Overall it is complete for an agent to select and invoke the tool correctly.

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

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

Schema description coverage is 64%, with descriptions for compact, include_items, owner_profile, hydration_limit, include_applied, and include_archived, but lacking for limit, profile, tenant_id, slate_limit, and section_limit. The tool description references 'bounded needs_role_hydration recovery' and '3-5 role slate,' adding context for hydration_limit and slate_limit, but does not add per-parameter meaning for all fields. It partially compensates but leaves some parameters to be inferred from 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 states 'Return the closed-loop Talent Scout daily operating report' with a specific verb and resource, and enumerates the report's sections (applied pipeline, mailbox status, follow-up due, etc.). It clearly distinguishes itself from sibling tools by adding 'Read-only control-tower view; no sends or applications,' making it obvious this is a reporting tool, not an action tool.

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 operational guidance: clients must not invoke their own Gmail/email connector, and must stop and surface the red receipt if mailbox_reconciliation_status is not ok. It does not name alternative sibling tools directly, but the 'closed-loop daily operating report' phrasing positions it clearly against tools like talent_scout_pipeline_describe or talent_scout_review_queue.

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