FlowVolt

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

With no annotations provided, the description carries the full burden. It discloses the creation of a standing order, meter event recording, and stub settlement. However, it omits details about idempotency, authentication requirements, rate limits, or error handling, leaving gaps 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 concise and well-structured: three sentences covering purpose, behavior, and return format. It front-loads the action and efficiently provides necessary context without 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 moderate complexity (2 optional parameters, no output schema, no annotations), the description is fairly complete. It describes the return format, current stub behavior, and the qualification note. Minor omissions include error states and order lifecycle, but overall adequate.

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

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

Schema description coverage is 100%, so baseline is 3. The description does not add significant meaning beyond the schema; for example, it repeats that 'requested_count' is an integer >=1 with default 1. No additional nuance or usage context is provided.

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

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

The description clearly states the tool's purpose: 'Order qualified, attended meetings from FlowVolt — the metered outcome (§12).' It specifies the action (order/create a standing meeting order) and the resource (qualified meetings), distinguishing it from siblings like 'list_meetings' (list) and 'find_leads' (search).

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

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

The description provides usage context by explaining the current stub behavior ('today the ledger records without charging') and future settlement integration. However, it lacks explicit guidance on when to use vs. alternatives or when not to use the tool.

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

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

With no annotations, the description carries full burden. It discloses the tool is always positive and grounded in user's numbers (no hype), and specifies the output includes expected revenue and a worst-case scenario. This confirms a read-only, non-destructive 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?

Three sentences, each earning its place: first states purpose, second gives usage trigger, third describes output and tone. No redundancy or fluff.

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

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

For a parameter-complete tool with no output schema, the description fully explains what is returned (expected revenue per month per plan, worst-case) and behavioral traits. It covers all necessary context for an agent 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 100%, so baseline is 3. The description does not add significant information beyond the schema; the schema already explains deal_value_usd and close_rate clearly. The description mentions returns per month per plan, but that is about output, not parameter semantics.

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

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

The description 'Show the math' is an informal but specific verb indicating calculation, and it clearly states what the tool does: returns expected revenue per month per plan plus worst-case. It uniquely distinguishes itself from siblings as the only calculator 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?

Explicitly says 'Call this whenever the user expresses doubt about pricing OR shares their deal value and close rate,' providing clear when-to-use guidance. Does not explicitly state when not to use or name alternatives, but the context is sufficient.

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

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

No annotations provided, so description carries full burden. It explains the tool returns the next question or final plan, describes final output content, and adds 'Always sequential and warm, never a form dump.' This covers behavioral traits well.

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 fairly concise with two paragraphs. It front-loads purpose and provides detailed context. Some redundancy in listing questions twice, but overall efficient.

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

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

Given the complexity of a 5-question intake with nested object schema and no output schema, the description fully explains the entire flow, each question's purpose, and what the final response contains. It is complete for an agent 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 coverage is high (all properties described), but the description adds value beyond schema by explaining the intake flow, sequence of questions, and how answers are used. It clarifies that answers are passed in and the tool progresses.

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: 'Tailor FlowVolt to the user's specific business via a 5-question intake.' It distinguishes well from sibling tools like book_meeting or get_quote by specifying it's for custom plans.

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

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

Explicitly says when to use: 'when the user wants a custom plan rather than a generic quote, or when they're unsure which plan fits.' It also advises to pass any existing answers. Lacks explicit when-not guidance but context is sufficient.

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

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

With no annotations provided, the description fully discloses behavioral traits: the 'voice guard' rules (no em dashes, no marketer words, length bounds) and the fallback behavior (suggest alternative). It does not cover authentication or rate limits, but the core behavioral constraints are well-communicated.

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

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

The description is concise (3-4 sentences) and front-loaded: first sentence states purpose, followed by illustrative examples and behavioral guardrails. Every sentence adds necessary context without redundancy.

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

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

For a tool with no output schema and moderate complexity, the description covers the essential usage, constraints, and error handling. It implies a response (success or alternative suggestion) but does not explicitly detail the return structure, leaving slight ambiguity 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 100%, so the schema already describes each parameter. The description adds value by providing concrete examples for 'change_request' and clarifying that changes are in plain English, going beyond the schema's minimal description.

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

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

The description clearly states the verb ('Change') and the resource ('first-touch template'), with specific examples of customer instructions. It distinguishes itself from sibling tools like 'preview_message' by focusing on natural language editing of templates with constraints.

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 explains when to use the tool ('based on the customer's instruction in plain English') and what happens when constraints are violated ('we say no and suggest a clean alternative'), but does not explicitly exclude 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?

No annotations provided, so the description fully covers behavior: idempotency ('same email won't be queued twice in 90 days'), deduplication behavior, and return format with two statuses and queue_id null case. This is comprehensive.

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

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

Three sentences with no filler. The first sentence states the main action, the second adds idempotency, the third provides usage context and return spec. Every sentence is necessary and well-structured.

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

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

Despite no output schema, the return format is fully described. The parameter schema is complete. All key aspects (purpose, idempotency, usage, return) are covered, making the description complete for this 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?

Schema description coverage is 100%, so the schema already documents all parameters. The description does not add additional meaning to individual parameters beyond what is in the schema, thus baseline 3 is appropriate.

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

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

The description clearly states the action ('Add'), the resource ('single prospect to the FlowVolt outbound queue'), and the context ('cold-email outreach'). It distinguishes itself from siblings like search_people by specifying the relationship. The idempotency detail further clarifies its 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?

Explicitly says when to use ('after search_people to push a revealed contact, or to add a known contact directly'). Does not mention when not to use or alternatives, but the context is sufficient 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 no annotations, the description fully discloses behavioral traits: sync operation, timing (30-60 seconds), free trial returns up to 15 buyers, topup returns a Stripe URL initially then buyers after payment, and the output format (name, work email, LinkedIn, etc.). No contradictions.

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

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

The description is well-structured, starting with a clear one-line purpose, then providing sequential details. It is concise yet informative, though slightly dense. No wasted sentences.

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

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

Given no output schema, the description explains return values clearly. It covers both free_trial and topup scenarios, including the payment retry logic. Parameter count is low, so completeness is adequate 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?

Schema covers both parameters with descriptions (email optional, quote_id from quote/discover). The description adds significant meaning beyond schema by explaining quote_id types and behaviors, which helps the agent understand how to set the parameter correctly.

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

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

The description clearly states the tool 'delivers in-market buyers' and explains the distinction between free_trial and topup quote_ids, making it easy to understand its purpose and differentiate from sibling tools like quote or discover_business.

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 explicit context on when to use the tool (after obtaining a quote_id from quote() or discover_business()) and how behavior differs for free_trial vs topup, including the payment flow. It lacks explicit 'when not to use' statements but provides sufficient 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?

No annotations provided, so description carries full burden. It discloses the tool computes and returns metrics, implying read-only behavior. However, it does not mention potential side effects, authentication, rate limits, or other behavioral traits beyond the stated 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 two sentences, front-loaded with the main action and output, and includes a usage example. Every sentence is purposeful and concise.

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

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

Given no output schema, the description provides the return object structure. It covers purpose, usage, and parameters adequately for a simple tool with two parameters. Could include pagination or error handling but not necessary.

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

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

Schema coverage is 100% with descriptions for both parameters. The description adds context about the overall function and output but does not add significant meaning beyond the schema for the parameters. Baseline 3 applies.

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

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

Description clearly states the tool computes pipeline funnel metrics for a date range and mentions specific metrics. It gives an example question. However, it does not explicitly differentiate from siblings like get_pipeline or get_replies.

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

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

Description explicitly states when to use the tool ('for any quantitative question about pipeline performance') with an example. It does not mention when not to use or alternatives, but the guidance is clear.

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

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

No annotations exist, so the description bears full burden. It states the return shape (object with keys and status counts) and implies read-only retrieval but does not disclose potential side effects, authentication requirements, or rate limits. Adequate but not rich.

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

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

Two sentences, no fluff. The first lists stages, the second gives usage and return format. Perfectly concise and front-loaded with the most important information.

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

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

For a parameterless tool with no output schema, the description fully explains what the tool returns (the pipeline stages and status counts) and when to use it. No missing information.

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

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

The input schema has no parameters (0 params, 100% coverage). The description adds no parameter details because none exist, which is appropriate. It adds value by explaining the output structure beyond the schema.

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

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

The description clearly states the tool returns the v2 deep-signal pipeline stages (discovery, signals, dossiers, touches, outcomes) for the tenant, with a specific verb 'get' implied. It distinguishes from siblings like get_funnel by specifying 'deep-signal pipeline'.

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

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

Explicitly provides a use case: 'Use for any "where are my meetings coming from / what's in flight" question.' This guides when to use the tool. It does not explicitly state when not to use, but the sibling names (e.g., get_funnel, get_receipts) imply alternatives.

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

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

With no annotations, the description carries the full burden. It discloses the conditional output format and the immutability of receipts when outcome exists. It does not mention read-only nature or rate limits, but the described behavior is transparent and sufficient for safe use.

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 packed with information without being overly long. Each sentence adds value, and the structure front-loads the key concept. Slight wordiness (e.g., 'provable receipt chain') is justified by clarity.

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

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

Given the tool has two optional parameters, no required ones, and no output schema, the description fully covers the return structure and behavioral nuances. It is complete for an agent to select and invoke correctly, especially with the contextual mention of receipt immutability.

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%, but the description adds significant value by explaining how each parameter affects the response: 'limit' controls the summary list, 'account_domain' triggers the full chain. This goes beyond the schema's basic descriptions and enhances understanding of parameter behavior.

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

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

The description clearly states the tool retrieves the 'provable receipt chain' and distinguishes two modes: without account_domain returns a summary list of accounts with stage statuses, with account_domain returns the full chain. This is specific and verb+resource oriented, and it differentiates from sibling tools which likely operate on different data.

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

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

The description explicitly explains when to use each mode based on the presence of account_domain. It does not compare with sibling tools but provides clear context: use without for summary, with for full chain. This is sufficient guidance, though it could 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?

No annotations provided, so description carries full burden. It discloses detection of forwarded threads and lists classification values, implying a read-only operation. It does not explicitly state non-destructive nature but gives sufficient context for behavior.

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

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

Two sentences: first states purpose and triggers, second gives return structure. Front-loaded, no unnecessary words, every sentence earns its place.

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

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

Given no output schema, the description provides the full return structure and classification values. It is adequate for a simple retrieval tool, though it could mention default limit or ordering.

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

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

Schema coverage is 100% with clear descriptions. The description adds value by explaining the 'positive' and 'all' classification filters beyond the enum, enhancing parameter understanding.

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

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

The description clearly states 'Fetch recent inbound replies from prospects' with a specific verb and resource, and adds a distinguishing feature 'with detection of forwarded threads'. It uniquely identifies the tool among siblings like 'get_receipts' and 'get_pipeline'.

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

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

Explicitly tells when to use: 'when the user asks who replied, what they said, or wants to triage the inbox'. However, it does not explicitly state when not to use or compare to sibling tools, though the domain is clear.

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

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

With no annotations provided, the description fully explains tool behavior: 'Returns a warm explainer in plain language: what FlowVolt does, why it works, vocabulary, and six pricing options. Offers either a 5-question discovery or a direct quote.' It does not mention side effects or permissions, but for a read-like tool this is acceptable.

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

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

The description is longer than necessary, with multiple clauses and examples. It is front-loaded with the key instruction, but the additional explanatory sentences could be condensed. Adequate but not optimally concise.

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

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

Given the tool has no output schema, the description fully explains the return value (explainer with content, options). It covers purpose, usage, parameters, and outcome, making it 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?

Both parameters are described in the schema, but the description adds usage guidance: 'their first name if you know it from the conversation context, otherwise leave blank' for name, and 'their business name if known or mentioned' for company. This goes beyond the schema descriptions.

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

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

The description clearly states the tool is for initial onboarding: 'Call this the moment the user connects FlowVolt OR asks anything that means 'what is this''. It specifies the verb ('call this') and resource (FlowVolt introduction), distinguishing it from sibling tools like 'discover_business' or 'subscribe'.

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

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

The description explicitly tells when to invoke the tool: 'the moment the user connects FlowVolt OR asks anything that means 'what is this''. It gives clear context but does not explicitly mention when not to use it or list alternatives, though the sibling list implies differentiation.

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

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

No annotations are provided, so the description must carry the burden. It explains that the tool returns a human-readable summary and handles authenticated vs anonymous callers. However, it does not disclose potential side effects, latency, or other behavioral traits. With annotations missing, this is adequate but not comprehensive.

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

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

The description is concise (about 80 words) and well-structured: purpose first, then usage examples, then parameter instructions. Every sentence adds value without redundancy.

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

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

For a tool with only 2 optional parameters and no output schema, the description covers all necessary context: what the tool returns, authentication modes, and example queries. It is self-contained and sufficient for an agent to use 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%, providing basic descriptions for both parameters. The description adds context: 'Pass `name` if known so we greet them personally' and clarifies that `email` is for anonymous callers. This extra guidance enhances understanding beyond the schema.

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

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

The description clearly states the tool's purpose: 'Show the customer their current FlowVolt state in plain language' and lists specific fields (plan, billing, engine status, live progress). It also differentiates from sibling tools by focusing on a broad overview, not specific sub-features like get_funnel or get_pipeline.

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

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

The description provides explicit usage scenarios: 'Use whenever they ask ...' with example queries. It also explains authentication handling and parameter conditions. However, it does not explicitly mention when to avoid using this tool in favor of siblings, which limits 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?

With no annotations provided, the description fully explains the return format and semantics, including the status field conditions. It also implies the tool is a read operation by nature of retrieval.

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 plus an inline return format example. Every sentence earns its place with no redundancy.

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

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

Given no output schema, the description provides the return structure and field explanations. It covers purpose, parameters, usage, and output completely for a filtered list tool.

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

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

The input schema already describes both parameters with examples (ISO 8601), so the description adds no new semantic value beyond mentioning the date range context. Baseline 3 is appropriate.

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

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

The description clearly states 'Retrieve meetings booked from FlowVolt outreach in a date range,' specifying the exact resource and action. It distinguishes from siblings like book_meeting (different action) and get_funnel (different resource).

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

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

The description explicitly lists use cases: 'Use for meeting counts, pipeline evidence, or "what's on the calendar" questions.' This provides clear context without exclusions or alternatives.

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

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

No annotations are present, so the description must carry the burden. It says 'open the Stripe-hosted billing portal' but does not describe the actual behavior (e.g., returns a URL, opens a new window, requires authentication, or any side effects). The outcome for the agent is unclear.

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, no wasted words, front-loaded with the core function. Efficient and clear.

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

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

The description covers the use case but fails to specify the output or result of the tool (e.g., returns a URL). Given no output schema, this is a notable omission for completeness.

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

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

Schema coverage is 100%, and the description does not add meaningful information beyond what is already in the schema parameters. The baseline of 3 is appropriate as the description adds no extra value.

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 opens the Stripe-hosted billing portal for specific actions (cancel, switch plans, update card, download invoices), with a specific verb and resource. It distinguishes from siblings like get_subscription_status and subscribe by specifying its use case.

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?

Explicit usage guidance is provided: 'Use when they say cancel, update my card, change plan, where are my invoices.' While no negative usage or alternatives are given, the 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?

With no annotations, the description discloses key behaviors: stops queued and in-flight sends, leaves billing active. Does not cover reversibility or auth, but is sufficient for a pause action.

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

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

Three concise sentences front-load the core action, clarify boundaries, and provide usage guidance. No unnecessary words.

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

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

Lacks description of return values or confirmation behavior, which is needed since no output schema is present. However, the tool's function is simple and context from siblings fills gaps.

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

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

Schema coverage is 100% and parameters are well-described in the schema. The description adds no additional semantic value beyond what the schema provides.

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

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

The description clearly states the verb (Pause) and resource (sends), and distinguishes from sibling tools like resume_engine by specifying that sends are stopped and billing continues, which is unique.

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

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

Explicitly provides natural language triggers for when to use ('pause', 'stop sending', etc.) and directs to an alternative (manage_billing) for cancellation.

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

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

Description implies read-only behavior ('show') and lists output fields. No annotations provided, so description carries full burden; it adequately conveys no side effects, though does not mention failure modes or permissions.

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, no wasted words. First sentence states purpose and content, second gives usage examples. Highly 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?

Tool is simple preview with 2 optional params; description covers output, usage context, and is sufficient for a simple tool. No output schema needed given the clear enumeration of returned fields.

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% (both parameters described in schema). Description does not add extra meaning beyond schema; parameters are optional and contextual (name, email). 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?

Clearly states the verb 'show' and resource 'current first-touch template', and lists returned content (subject, body, tone notes, word count). Differentiates from sibling 'edit_message' by focusing on preview.

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

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

Explicitly provides exact customer phrases that trigger this tool: 'show me what you'd send', 'what's the email', 'let me see the copy'. No guidance on when not to use, but context is clear.

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

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

With no annotations, the description carries full burden. It states the tool takes a natural-language description and returns six plans in plain prose, which is transparent about behavior. However, it lacks details on error handling, auth requirements, or side effects, leaving minor gaps.

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

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

Three sentences, each serving a distinct purpose: stating the tool's role, describing input/output, and providing usage guidance. No wasted words; efficient 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 no output schema, the description adequately explains the output format ('returns six plans in plain prose') and mentions the sibling alternative. It lacks details on potential errors or response structure but is sufficient for a tool with fixed output.

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

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

Schema covers 100% of parameters with descriptions. The description adds value beyond the schema by reinforcing that name and company are optional ('pass if you know them') and clarifying that use_case is a natural-language description. This enhances parameter understanding.

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

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

The description clearly states the tool's purpose as a 'direct quote path' for pricing or finding leads when the user already knows their target. It specifies the output ('returns six plans in plain prose') and distinguishes it from the sibling tool discover_business, 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?

Explicitly says when to use (user knows who they want to reach) and when not (use discover_business for users without an expressed ICP). Also advises to pass name and company if known, providing clear actionable 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?

No annotations provided, so description carries full burden. It explains that after resume, sends go to calibration first then full speed, which is a helpful behavioral detail.

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 plus a usage line. Extremely concise with no wasted words; 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?

Given no output schema and two optional parameters, the description is fairly complete. Explains the post-resume behavior. Could mention preconditions (e.g., engine must be paused) but adequate.

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

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

Schema description coverage is 100%, so baseline 3. The description does not add extra meaning beyond the schema's parameter descriptions.

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

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

The description clearly states the action ('Resume the engine') and adds context about calibration and full speed, distinguishing it from siblings like 'pause_engine'.

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

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

Explicitly tells when to use: when user says 'resume', 'restart', etc. Does not mention when not to use or compare to other tools, but given simplicity, it's sufficient.

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

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

No annotations are provided, so the description carries full burden. It discloses credit costs, caps, and return structure. However, it does not mention authorization requirements or potential side effects.

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

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

The description is concise with two sentences plus return format. It is front-loaded with purpose and has no unnecessary information.

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

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

Given no output schema, the description includes return fields. It covers credit details and parameter groupings. However, it omits prerequisites or explanation of 'cache_breakdown.'

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%, baseline is 3. The description adds minimal meaning beyond the schema, mainly by grouping parameters under 'ICP filter.' It does not provide significant additional context.

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

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

The description clearly states the tool finds B2B prospects matching ICP filters and returns verified emails. It uses specific verbs and resources but does not explicitly distinguish it from sibling tools like find_leads.

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 says to use when the user asks for leads, prospects, or decision-makers. It provides usage context but lacks explicit when-not-to-use instructions or alternatives.

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

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

Without annotations, the description explains that the Conductor reads the goal every run to allocate capacity, and that setting status to 'paused' excludes the tenant from plans. It doesn't mention authorization or rate limits, but for a simple parameter-setting tool, this is adequate transparency.

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

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

The description is four sentences, each serving a distinct purpose: defining the tool, explaining its importance, providing usage guidance, and stating return format. No unnecessary words; front-loaded with the core purpose.

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

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

Given the tool's simplicity (2 parameters, no output schema, no annotations), the description covers purpose, usage, behavior, return format, and parameter semantics. It feels complete and leaves no obvious gaps.

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

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

Schema coverage is 100%, so baseline is 3. The description adds value by specifying the return format and explaining the 'status' parameter's effect (pacing gate, excludes tenant). It slightly enhances understanding beyond the schema's descriptions.

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

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

The description clearly states the tool sets the tenant's meeting goal (weekly qualified-meeting target). The verb 'Set' and resource 'tenant's meeting goal' are specific, and the explanation distinguishes it from sibling tools like book_meeting or find_leads which deal with different actions.

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

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

The description explicitly says when to use: 'when the calling agent (or operator) wants more or fewer meetings per week, or to pause/resume the engine for this tenant.' It provides clear context but does not list alternatives or exclusions; however, sibling tools are different enough that confusion is unlikely.

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 fully discloses the behavior: returns a Stripe Checkout URL, triggers engine start upon payment, provides MCP token, and includes a free month condition. No annotations exist, so the description carries the full burden and excels.

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

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

The description is concise with four sentences, each adding necessary detail. It front-loads the main action and efficiently explains the flow without redundancy.

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

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

For a single-parameter tool with no output schema, the description covers the input requirements, the output (URL), and the post-payment process, making it complete and self-contained.

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%, providing a baseline of 3. The description adds value by specifying that quote_id must come from specific functions and have a plan, which is beyond the schema description.

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

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

The description clearly states the tool starts a monthly plan, a distinct action among siblings. It specifies the verb 'start' and the resource 'monthly plan', making its purpose unambiguous.

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

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

The description explains that the tool requires a quote_id from quote() or discover_business() with specific plans, setting clear prerequisites. However, it does not explicitly state when not to use it or list alternatives.

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