Word Is Bond

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

No annotations provided, and description fails to disclose side effects (e.g., creation, persistence), authentication needs, or conditions like number verification for PSTN targets.

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-load the main purpose, but could be more structured to separate primary action from optional features.

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

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

Covers key aspects but omits return value (no output schema) and PSTN verification requirement found in schema, leaving minor gaps for complex nested parameters.

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

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

Adds meaning beyond schema by explaining 'reusable', 'pinned', schedule cadences, and target agent purpose. Schema coverage is high (~80%), but description compensates well.

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 reusable test suite with scenarios/personas pinned to a target agent, distinguishing it from siblings like list_suites or run_test.

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?

Mentions optional schedule for automated drift detection but lacks explicit guidance on when to use this vs. one-off tools like run_test or demo tools like run_demo.

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

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

No annotations are provided, so the description carries the full burden. It clearly states the tool produces a diff output and implies it is a read-only operation ('see exactly what a change did before you ship it'). It does not explicitly disclose error handling or authentication, but the behavioral scope is well-defined and non-destructive.

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 core action and reinforced by a helpful metaphor. No unnecessary words or repetition.

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

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

For a diff tool with simple inputs, the description fully explains the output (nodes and edges changes) and context (review before shipping). No output schema is needed, and no additional links to other tools are required 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?

The input schema covers all three parameters with clear descriptions (100% coverage). The description does not add further semantic details beyond the schema, such as expected formats or constraints. Baseline of 3 is appropriate.

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

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

The description clearly states the action ('show the structural diff'), the resource ('two versions of a version-controlled flow'), and the specific details ('which nodes and edges were added, removed, or changed'). The metaphor 'code review for your phone system' further clarifies the purpose. No sibling tool duplicates this functionality.

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

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

The description implies usage context ('see exactly what a change did before you ship it') but does not explicitly state when to use this tool versus alternatives (e.g., test_flow, run_test) or when not to use it (e.g., for functional testing). No exclusions or prerequisites are mentioned.

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

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

No annotations are provided, so the description carries the full burden. The description starts with 'Read' implying read-only, but doesn't elaborate on additional behavioral traits (e.g., data latency, rate limits, or side effects). This is adequate but not exhaustive.

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

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

Two concise sentences: the first states the tool's output, the second provides usage guidance. No unnecessary words 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 one optional parameter and no output schema. The description lists the key outputs (pass-rate, average score, regressions, totals) and mentions aggregation per suite, but does not detail the exact output structure. This is fairly complete for a read tool of moderate 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% for the only parameter 'days'. The description mentions 'over a window' but does not add new meaning beyond the schema's description. 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 tool reads account-wide testing trends with specific metrics (pass-rate, average score, run-to-run regressions) and differentiates from sibling tools like run_test and list_suites by focusing on trend analysis.

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 states when to use it ('spot behavior drift in voice agents'), providing clear context. It doesn't mention when not to use or alternatives, but the context alone is sufficient for an AI agent.

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

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

With no annotations, the description carries full burden. It discloses reporting of abstracted fields and reversibility (IR exports back out). No contradictions, but could detail authorization or side effects.

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

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

Two focused sentences, no wasted words. The core action is front-loaded, followed by key behavioral details. Perfectly 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?

Description covers purpose, outcome (reporting fields), and bidirectional use. Lacks output schema details and error handling, but given complexity (4 params, nested objects), it's reasonably complete.

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

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

Schema coverage is 100%, but the description adds context beyond schema descriptions (e.g., save as versioned flow, migration surface). This enhances agent understanding beyond raw parameter docs.

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

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

The description clearly states it imports a flow/config from a platform into a canonical IR, with specific verb 'import' and resource 'phone-system flow or voice-agent config'. It distinguishes from siblings like diff_flow and test_flow as the first step of version control.

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 positions the tool as the first step under version control and mentions optional save:true for persistence. It implicitly guides when to use, but doesn't explicitly state when not to use or provide alternatives.

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

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

The description discloses return fields (ids, names, targets, schedules) and implies a read-only operation. No annotations are provided, so the description carries the burden, and it does so effectively without contradiction.

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

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

Two sentences with no wasted words. The first defines the resource, the second lists return fields and provides cross-reference usage. 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?

Given no parameters and no output schema, the description fully covers purpose, return fields, and integration with related tools. No gaps remain.

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 zero parameters, so baseline score is 4. The description does not need to add parameter information because there are none.

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

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

The description clearly states the tool lists 'your reusable test suites' and explains what they are, distinguishing it from sibling tools like create_suite (create), run_test (run), and list_verified_numbers (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 implies usage by stating 'use a suite id with run_test or get_trends,' but does not explicitly differentiate from other list tools or provide when-not-to-use conditions.

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

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

With no annotations, the description carries full burden. It identifies the tool as a read operation listing verified numbers and notes the eligibility for pstn targets, but fails to disclose any behavioral traits such as authentication requirements, rate limits, or response format.

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

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

The description is three sentences long, each adding distinct value: action, usage context, and a pointer to deletion. No waste; front-loaded with the primary 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 simple list tool with no parameters and no output schema, the description is fairly complete. It explains what is listed, why it matters, and how to revoke numbers. It could mention pagination or result format to be fully comprehensive.

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 zero parameters, so the baseline for this dimension is 4. The description adds no parameter information, but none is needed. It correctly implies no parameters are required.

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

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

The description clearly states the verb 'List' and the resource 'verified numbers'. It specifies that these are numbers the account has proven to control, and distinguishes from DIDs. It aligns well with sibling tools like verify_number_start.

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

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

The description implies usage for viewing controlled numbers and mentions they are necessary as pstn targets, but does not explicitly state when to use this tool versus alternatives like verify_number_start or list_suites. It provides context but lacks explicit guidance.

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

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

The description discloses key behaviors: wordis-bond never stores audio, only a pointer; callbackUrl never holds cloud credentials; plan restrictions (starter → 402). Given no annotations, this is strong, but lacks info on errors or return format.

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

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

The description is reasonably concise (3-4 sentences) and front-loaded with the main purpose. Every sentence adds value, though it could be slightly tighter.

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 should ideally describe the return value (e.g., target ID). It provides good integration context but omits success/failure details or what the tool returns, so a 3 is appropriate.

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 explaining the callbackUrl's purpose (presigned PUT URL, no credential storage) and noting track defaults. This extra context justifies a 4.

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

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

The description clearly states the tool's purpose: registering where BYOS call recordings go. It uses specific verbs ('register') and resources ('recording target'), and distinguishes from sibling tools like run_test by explaining the integration.

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

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

The description provides clear context for when to use this tool (for BYOS recording setup) and how to use it with run_test. It mentions plan restrictions but does not explicitly exclude alternatives, earning a 4.

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 run duration (~1 min), return values (score, verdict, metrics, transcript, URL), zero carrier cost, and optional overrides. It does not mention side effects or auth needs, but is fairly 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?

Two sentences, no wasted words. First sentence states the action and primary result. Second lists return details and adds context about cost and overrides. Front-loaded with key information.

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

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

The description lists all return values (score, verdict, metrics, transcript, URL) compensating for no output schema. With 5 parameters (all optional) and nested objects, it provides sufficient context. No mention of errors, but for a demo tool this is adequate.

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

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

Schema coverage is 100%, so baseline is 3. The description adds 'Optional inputs override the scenario' but provides no additional per-parameter meaning 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 uses a specific verb 'Run' and resource 'hosted demo voice agent', clearly stating it provides a fully-scored result in about a minute. It distinguishes itself from siblings by noting 'no target of your own needed', which contrasts with run_test.

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 what the tool does and when to use it (running a hosted demo without a target). It mentions optional inputs override the scenario, giving context. However, it lacks explicit when-not-to-use guidance or direct comparison to run_test.

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 details behavioral traits: synchronous vs async, polling requirement, error codes (403), transport costs, and prerequisites for PSTN.

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?

Well-structured with mode separation and front-loaded purpose, but slightly verbose given the complexity; 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 15 parameters, complex modes, and no output schema, the description sufficiently covers what to expect (sync vs async, polling) and how to interpret results, though return value details are omitted.

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 87% schema coverage, description adds value by grouping parameters by mode and explaining interrelations, though some parameters (e.g., bargeIn, expected) lack 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 runs tests against a voice agent, specifying two distinct modes (offline scoring and live synthetic call) and differentiating from sibling tools like run_demo and create_suite.

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

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

Provides explicit guidance on when to use each mode and necessary prerequisites (e.g., verified number for PSTN), but lacks explicit exclusion of alternatives like run_demo.

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 description must cover behavior fully. It describes the process but lacks details on side effects (e.g., does it create/modify resources?), auth requirements, or safety. The 'blocks the change' is vague.

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 action. The second sentence is somewhat long but still clear. Could be slightly more concise without losing 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?

Given the tool's complexity (regression gate) and lack of output schema, the description explains the core logic well. However, it doesn't describe what the block looks like or return values, leaving some gaps.

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

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

Schema coverage is 100% for the single flowId parameter. Description adds context about the gate action but does not provide additional meaning for the parameter beyond its ID nature.

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

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

The description clearly states it runs a regression gate on a flow, compiling, testing, and comparing to baseline. It distinguishes from siblings like run_test or diff_flow by focusing on regression detection in CI context.

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

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

Description implies use for regression testing after flow changes, but does not explicitly state when not to use it or provide alternatives. The CI context is clear, but more direct guidance would help.

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 key behaviors: the code is single-use, expires after ten minutes, and locks after five incorrect attempts. It also states the success outcome (number becomes a permitted PSTN test destination). This is sufficient behavioral context, though it does not detail error handling or side effects.

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

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

The description is extremely concise: two sentences that pack the essential purpose, outcome, and constraints. No fluff or redundancy. 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 and no annotations, the description covers the tool's purpose, behavior, and constraints well. It could hint at the prerequisite of calling verify_number_start first, but the sibling tool name implies the sequence. Overall, it is complete for a simple confirmation 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 has 100% coverage with descriptions for all three parameters (code, label, number). The tool description does not add new information about these parameters beyond the schema; it only provides overall context. Baseline 3 is appropriate since the schema already handles parameter semantics.

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

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

The description clearly states the tool's purpose: 'Finish verifying a phone number by supplying the 6-digit code spoken on the verification call.' It specifies the verb ('finish verifying'), resource ('phone number'), and action ('supplying the 6-digit code'). The outcome is also clearly described: 'On success the number becomes a permitted PSTN test destination.' This distinguishes it from the sibling tool 'verify_number_start'.

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

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

The description provides context for using this tool: it is the second step after a verification call. Behavioral details (single-use code, 10-minute expiry, 5 incorrect attempt lockout) guide the agent on when and how to use it promptly. However, it does not explicitly name alternatives or state when not to use it, though the context from sibling tools makes it 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 fully discloses behavior: places a short call, speaks a 6-digit code twice, requires confirmation within 10 minutes, and is tightly capped. This is comprehensive and trustworthy.

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, front-loaded with purpose, and each sentence adds value. Slightly verbose but 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?

No output schema, but the description explains the action well. Missing details on return values (e.g., verification ID), but acceptable for a trigger action tool.

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

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

Schema coverage is 100%, and the description does not add parameter-specific info beyond the schema's E.164 requirement. However, the description adds useful context about the verification process, so a 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 tool's purpose: to prove account control over a phone number before PSTN test calls. It uses specific verbs ('prove', 'places') and resource ('phone number'), and distinguishes from sibling tools like verify_number_confirm and list_verified_numbers.

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 states when to use (before PSTN test calls) and what not to use (already-verified numbers). Provides context on capping limits and mentions the alternative verify_number_confirm for completing verification.

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