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

With no annotations provided, the description carries the full burden of behavioral disclosure, and it delivers. It details the read-merge-write flow, auto-creation of company-level tags, silent filtering of empty/whitespace entries, dropping non-strings with a warning, de-duplication, a 100-tag cap, and the error condition when no valid tags remain. This is exceptional transparency for a mutation tool.

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

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

The description is well-organized with an opening purpose sentence, usage guidance, edge-case behavior, then an Args/Returns block. Every sentence contributes unique information—no filler or redundancy. The structure front-loads the key distinction and then logically details parameters and 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?

Given the tool's moderate complexity (3 parameters, edge cases around cleaning and limits) and absence of annotations/output schema, the description is complete. It explains return format, error behavior, and all parameter constraints. An agent has everything needed to call it correctly without additional context.

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

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

Schema description coverage is 0%, so the description must compensate entirely. It does: for call_id it specifies the 'CAL...' format; for tags it explains string-only, non-strings dropped, de-duplication, max 100; for account_id it notes auto-resolution when omitted. This adds meaning far beyond the bare schema and covers all parameters thoroughly.

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 'Append tags to a call WITHOUT replacing existing ones,' which states a specific verb, resource, and critical semantic (append vs. replace). It explicitly differentiates from update_call, making the tool's purpose unmistakable even without reading the schema.

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 when-to-use guidance: 'Use this when you want to add labels... without losing prior tags.' It also names the alternative for replacement: 'To fully replace tags, use update_call(tags=[...]) instead.' This is direct and actionable.

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 discloses the safety default (`dry_run=True`), the 500-call hard cap, client-side vs server-side filtering, race protection with extra GETs, and the non-reversible spam marking. It also details the deprecated `answered` parameter's historical failure mode. This is exemplary transparency beyond any annotation coverage.

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 lengthy but each section earns its place: motivation, safety, parameter semantics, return format, performance note. It is front-loaded with the core purpose and safety. Slight redundancy exists (e.g., repeating the 500-cap in the performance note and safety section), but the structure is clear with headings. It could be tightened slightly but is well organized.

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, zero schema coverage, no annotations, and an output schema that only partially covers return values, the description provides everything needed: parameter semantics, defaults, side effects, failure modes, performance implications, and return format. It is complete for an agent to invoke correctly without additional context.

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

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

Schema coverage is 0%, so the description must fully explain each parameter. It does: `company_id` and `days` are tied to `list_calls` semantics, `answer_status` is a server-side filter with enumerated values, `answered` is deprecated alias with a historical caveat, `source` is applied client-side, all `set_*` fields are explained with behavior (add vs replace), `dry_run` default, and `account_id` auto-resolution. It also documents the return object structure. This is comprehensive and compensates completely for 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 clearly states a specific verb ('Apply the same update to every call matching a filter'), the resource ('calls'), and the scope of operation. It provides concrete examples and distinguishes it from the sequential `update_call` tool, which is its primary sibling. The purpose is unmistakable and well differentiated.

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 this tool: for bulk operations 'Replaces dozens of sequential `update_call` invocations with one tool call.' It also provides negative guidance: 'At least one filter must be provided to avoid "update everything ever"' and warns about the `answered` deprecation. Alternatives are referenced (`list_calls`, `update_call`). This is thorough and actionable.

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 carries the full burden of behavioral disclosure. It explains the internal detection logic (using source slug and gclid, not source_name) and the configurable duration threshold, which adds valuable context. It does not explicitly state that the tool is read-only, but 'audit' strongly implies no side effects. It also mentions the return format (verdict + pass/fail + remediation), which is helpful. It doesn't cover error handling or rate limits, but for a read-only diagnostic tool, this is sufficient.

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 structured with a clear opening purpose, a numbered list of checks, and a separate paragraph for parameter semantics. It front-loads the main purpose and then provides organized detail. Every sentence adds value, and the structure makes it easy for an agent to parse. It is appropriately detailed without being verbose.

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

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

The description is complete for the tool's complexity. It covers the eligibility criteria, the parameters, and the return format (verdict + pass/fail + remediation). The output schema is not shown, but the description already summarizes what the output contains. There is no missing information that an agent would need to call this tool correctly.

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

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

Schema description coverage is 0%, so the description must compensate. It does so thoroughly: it explains call_id ('CAL... id'), google_ads_min_duration_seconds (threshold, default 60, override rationale), and account_id (auto-resolves if omitted). Each parameter's meaning and usage are clearly articulated, going well beyond the bare schema defaults and 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 states a clear, specific purpose: auditing whether a call is eligible as a Google Ads conversion, explicitly tied to 'where did my conversion go' debugging. It names the exact verb and resource and distinguishes itself from sibling tools like get_call and call_summary by focusing on eligibility criteria rather than general call 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 clearly indicates when to use the tool (for conversion debugging) and outlines the checks performed, which implies its scope. It doesn't explicitly name alternative tools for different use cases, but the debugging context and specific checks make the intended usage clear. A minor gap is not explicitly stating when not to use it (e.g., for general call details), but this is adequately 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?

With no annotations, the description fully carries the behavioral burden. It explains the server-side aggregation model, one-request behavior, default lookback, date precedence, field defaults, account auto-resolution, and the exact JSON return shape. This is unusually transparent for a read-style aggregation endpoint.

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 well-organized with clear Args and Returns sections. Every parameter has a purpose, and no filler sentences exist. Given seven parameters and the need to explain alternative selection, the length is justified.

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 is fully documented for safe, correct invocation: parameter semantics, default behavior, sibling-tool differentiation, and return structure are all present. The only omitted details are operational concerns like auth or rate limits, which are not required for an agent to select and call this tool correctly.

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

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

Schema description coverage is 0%, so the description must fully document parameters. It does: group_by enumerates valid values, days and fields have defaults, start_date/end_date get format and precedence rules, company_id is explained, and account_id's auto-resolution is noted. This compensates completely for the empty 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 this tool performs server-side call aggregation via CallRail's /calls/summary.json endpoint and returns grouped totals in a single request. It also distinguishes itself from call_summary, making its purpose and scope unmistakable.

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 the agent when to prefer this tool over call_summary ('when you only need grouped totals') and when call_summary is still useful. This gives actionable routing guidance beyond a generic tool description.

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 carries the full burden of behavioral disclosure. It reveals the output contents (counts, breakdowns), and importantly discloses the risky default behavior (pagination of 50+ pages of 250 calls) when no window is provided. It does not mention permissions or rate limits, but the key behavioral trait is covered.

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: a clear opening statement, a summary of return values, a usage note, and a behavioral warning. Every sentence earns its place, 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?

Given the tool's complexity and the existence of an output schema (which specifies return structure), the description is largely complete. It covers purpose, usage, and a critical behavioral caveat. The only minor gap is the lack of explanation for account_id and company_id, but these are likely standard filters and the description is adequate overall.

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 explain parameters. It explicitly explains days and start_date in the note, but does not mention end_date, account_id, or company_id. Those are left to inference. While the critical parameters are covered, the omission of the filter parameters means the description doesn't fully compensate for the schema gap.

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

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

The description clearly states the verb ('Summarize') and resource ('calls') and specifies the date-window scope. It distinguishes itself from sibling tools like list_calls by emphasizing aggregate counts instead of individual call data, and the mention of 'weekly/monthly rollups without pulling every call into context' makes 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 provides clear when-to-use guidance: for rollups and aggregate statistics, contrasted with pulling individual calls. It also gives an explicit usage constraint (requires days>=1 or start_date) and explains the consequence of violating it (pagination of entire history). While it doesn't name a specific alternative tool, the implication is strong enough to guide an 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 available, the description carries the full behavioral burden and does so thoroughly: it discloses the 200-point limit, the pre-flight check that avoids raw 400s, date precedence rules, default interval behavior, account auto-resolution, and the return shape. Nothing in the text contradicts 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?

Despite covering seven params, the description is organized with a short lead, a limit warning, an Args block, and a Returns block. Each line adds useful information, and the most decision-relevant behavior (limit and interval workaround) 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 seven-parameter time-series tool, the description covers valid values, date precedence, limits, filtering, and expected output. An agent has enough information to construct a correct call and to reason about failures before invoking.

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 explain every parameter, and it does: days default/ignored when start_date given, explicit YYYY-MM-DD dates, company filtering, valid field names, interval choices, and auto-resolved account_id. This is exactly the compensation needed for a bare 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 identifies a specific resource ('CallRail's /calls/timeseries.json') and a clear purpose: call volume over time as a trend line. It is easy to tell this is a time-series aggregation tool, though it does not explicitly contrast itself with sibling tools such as call_summary or call_stats.

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 when the tool is appropriate ('One request for a trend line instead of client-side bucketing') and practical guidance on interval options for longer windows. It does not explicitly list when-not-to-use or name alternative sibling tools, 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?

No annotations are provided, so the description carries the full burden. It clearly discloses implementation nuances: tracker counts use current-snapshot for both periods (not historical), and only minute deltas are period-over-period. This is exactly the kind of behavioral context an agent needs to avoid misinterpretation of results. It also notes that account_id auto-resolves if omitted, which is a behavioral trait.

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 with clear sections ('Args', 'Returns', 'Implementation'). It front-loads the core purpose and output, then details parameters and caveats. Every sentence adds value, with no filler. The use of examples ('is Malick growing?') is concise and effective. Ideal length for the complexity.

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 an output schema, so return format is covered there. The description provides essential usage context, parameter semantics, and behavioral caveats. The only minor gap is not mentioning potential side effects (or lack thereof), but given it's a read-only comparison, this is acceptable. Overall, it's complete 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?

Schema coverage is 0%, so the description must explain both parameters. It does: 'days' is explained with default, cap, and rationale; 'account_id' is explained as auto-resolving if omitted. This is above the baseline of 3 for low coverage, though it could be more explicit about what account_id refers to (e.g., a specific CallRail account). Still, it adds significant meaning beyond the bare 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 ('Compare') and resource ('current N-day window vs the previous N-day window'), and states its output (per-company deltas, agency totals). It clearly distinguishes itself from sibling tools like 'call_summary' and 'call_timeseries' by focusing on period-over-period comparison. The examples ('is Malick growing?') add practical context.

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

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

The description provides concrete use cases ('catching invoice surprises before they hit') and sets expectations about the 'days' parameter (default 30, cap 365, with a hint about typo prevention). It implicitly signals when not to use (don't ask for 5-year delta), which is useful guidance. However, it doesn't explicitly name alternatives, but the guidance 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 carries the full behavioral burden. It discloses that creating a company is free, that optional booleans default to None (inherit account defaults), and that sending False can actively disable paid features. This is valuable, non-obvious behavior beyond what the schema states. It does not detail response behavior, but an output schema is present, so that omission 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 organized with a clear purpose statement, a billing context sentence that earns its place, and a parameter list with concise inline explanations. The important warning about False versus None is front-loaded into the note section. There is no filler or redundant restating of the schema.

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

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

For a 9-parameter creation tool with no annotations)Skip? Actually no. Need final. Let's output.The description includes everything an agent needs: purpose, cost implications, parameter semantics, default inheritance behavior, and a dangerous edge case about False disabling paid features. The presence of an output schema covers return-value details. The only slight gap is not explicitly saying 'use update_company to modify an existing company,' but this is a minor omission given the clear onboarding context and the sibling list.

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

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

Schema description coverage is 0%, so the description must compensate. It does, covering all 9 parameters with meaningful semantics: name is required with an example, time_zone has a default and common values, each boolean explains what it toggles and that None means inherit, and account_id auto-resolves. This goes far beyond the bare schema titles and 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 opens with a specific verb and resource: 'Create a new company (client) under the account.' It then clearly positions the tool for new-client onboarding and distinguishes it from related tools like create_tracker. The purpose is unmistakable even before looking at the parameter schema.

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 guidance on when to use this tool ('Useful for new-client onboarding') and connects it to the billing model, pointing to create_tracker for the actual cost-bearing provisioning step. It does not explicitly enumerate exclusions versus update_company or list_companies, but the onboarding framing plus sibling reference is strong enough to route an agent 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?

With no annotations, the description explains parameter behavior (e.g., referrer constraints, field overrides) but does not disclose side effects, authorization needs, or irreversible actions beyond creation.

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

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

The description is well-structured with a purpose paragraph followed by parameter explanations, but the parameter list is a bit lengthy; could be slightly more 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?

Covers purpose, usage, and all parameters thoroughly; missing output schema details but output schema exists, so not required. Lacks error handling info.

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

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

Schema coverage is 0% but the description provides detailed explanations for all parameters, including required conditions, examples for form_data, and override rules, adding significant 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 'Manually create a form submission' and provides a concrete use case 'backfill an offline lead', making the purpose specific and easily distinguishable from sibling tools like update_form_submission.

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

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

Explicitly says to use when receiving a lead through a non-CallRail-tracked channel, but does not mention when not to use or compare to alternatives like creating a call directly.

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 lists parameters and hints at defaults (e.g., send_email default true) but does not disclose side effects, rate limits, authorization needs, or what happens on creation (e.g., immediate activation, duplicate prevention). The behavioral impact is inadequately described for a mutation tool with 12 parameters.

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 with a one-line summary followed by a detailed Args list. It is clear and front-loaded, but slightly verbose with full parameter names that are already in the schema. Every sentence earns its place, though trimming redundant descriptions could improve conciseness.

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

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

Given the tool's complexity (12 parameters, 0% schema coverage, no annotations) and availability of an output schema, the description covers the creation intent and parameter semantics adequately but lacks details on error handling, constraints (e.g., unique name), or post-creation behavior. It is minimally viable but leaves gaps for an agent to navigate confidently.

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

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

Schema description coverage is 0%, so the description must compensate. It provides meaningful context for most parameters: explains alert_type common values, optional scope filters, channel toggles, trigger toggles for mixed events, and auto-resolution of account_id. This adds significant value beyond the bare schema, though enums or more precise formats could be mentioned.

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 action ('Create a notification rule') and its purpose ('who gets pinged on which event'), distinguishing it from sibling tools like delete_notification, update_notification, and list_notifications.

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 prerequisites, when to modify vs create, or contexts where this tool is appropriate, leaving the agent to infer usage from the parameter list.

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

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

With no annotations provided, the description carries the full behavioral burden and does so thoroughly: it discloses that calls actually dial real phones, explains the two-leg dialing order and bridging behavior, warns that both legs consume minutes, flags legal risk, and mandates confirm_dialing=True as an explicit safety gate. This far exceeds typical descriptions.

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 most critical warning before diving into details. The parameter list is compact but every entry adds semantic value, and the version note about old parameter names prevents a known failure mode. No sentence is wasted.

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 high-stakes, side-effectful operation with eight parameters and no annotations, the description covers action, safeguards, geography, billing impact, parameter semantics, and return behavior. An output schema already exists, so the return-value note is sufficient. Nothing material is missing for an agent to invoke this tool correctly.

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

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

Schema description coverage is 0%, so the description must compensate for all eight parameters. It explains every parameter in plain terms, adds E.164 format expectations, identifies which leg each phone number represents, clarifies that confirm_dialing defaults to False and returns an error envelope, and notes that account_id auto-resolves. This fully compensates for the bare 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 opens with a specific verb and resource: 'Place an outbound call.' It adds a high-value qualifier, 'THIS ACTUALLY DIALS REAL PHONES,' which makes the tool's purpose unmistakable and differentiates it from read-oriented siblings like list_calls, get_call, and call_summary.

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 when to use the tool and includes explicit exclusions: 'US and Canadian numbers only' and 'CallRail does not support outbound to the UK or Australia via this endpoint.' It also stresses consent verification as a prerequisite. It does not name alternative tools such as call_eligibility_check, but the usage context is otherwise strong.

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 are absent, so the description bears the behavioral burden. It does disclose useful behaviors beyond the schema: tag scoping, account_id auto-resolution, and the gray1 color default. However, it does not mention side effects, permissions, error conditions, or duplicate/name constraints for the mutation.

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, front-loaded with the core purpose, and uses an Args block that maps cleanly to all four parameters. The color list is longer but necessary because the schema has no enum values.

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 4-parameter create mutation with no annotations and an output schema, this description is complete: it clarifies required versus auto-resolved fields, the relevant scoping rule, and valid inputs. Nothing the agent needs to invoke the tool correctly is left undocumented.

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 fully compensates: name, company_id, account_id, and color all receive meaningful guidance. The color parameter is especially strong, enumerating the 24 supported color ranges and stating the default.

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 opening line names an exact action and object: 'Create a new tag scoped to one company.' This is specific enough to distinguish it from sibling tag tools like list_tags, update_tag, delete_tag, and get_tag without ambiguity.

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 usage context: tags are per-company, company_id is required, and account_id auto-resolves. It does not explicitly route the agent to update_tag/delete_tag when appropriate, but the 'create' framing and per-company scope make the intended use 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 carries the full burden. It transparently discloses the financial impact, the need for explicit confirmation, the per-number billing multiplier for pool_size, the conditional ignoring of area_code for toll_free, and the return value. It also notes potential proration. These are critical behavioral traits beyond the schema.

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

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

The description is long but well-structured: it starts with a prominent warning and cost explanation, then a mandatory billing confirmation note, followed by a parameter-by-parameter breakdown. It is front-loaded with the most critical information. While verbose, each sentence carries useful content, and the organization (warning → requirements → parameter details) aids comprehension. No filler.

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

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

Given the tool's complexity (14 params, output schema present), the description is exhaustive. It covers all parameters, cost implications, conditional behaviors, and the return value. It also notes that account_id auto-resolves if omitted. Nothing an agent needs to call it correctly is missing; even the return statement is explicit.

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 fully, and it does. Every one of the 14 parameters is explained with meaning, defaults, constraints, and cross-relationships (e.g., source_type ignored for session, area_code ignored for toll_free, pool_size multiplied cost). Examples like 'Google Ads Call Extension' for name and valid source types are provided, adding substantial semantic 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 opens with a clear, specific action: 'Create a new tracking phone number (tracker).' It explicitly names the resource and distinguishes it from sibling operations (list, update, delete) by its creation purpose. The verb-resource pairing is 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 gives explicit usage context: it warns that creation costs money, mandates confirm_billing=True for actual creation, and explains the source vs. session type choice. It does not explicitly name alternative tools to use instead, but the cost and confirmation guidance strongly implies when this should be invoked. The instruction 'You must pass confirm_billing=True to actually create' is a concrete usage rule.

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

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

With no annotations, the description transparently discloses that the tool sends an invitation email and warns of side effects. It explains role behavior (unknown values accepted with warning) and account_id auto-resolution, though it does not mention rate limits or authentication requirements.

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

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

The description is well-structured with an 'Args' section listing parameters. Every sentence adds value: purpose, side effect warning, and parameter details. No repetition or filler.

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

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

Given 6 parameters, 3 required, and the presence of an output schema (which removes the need to describe return values), the description is complete. It covers all input details, side effects, and parameter nuances.

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 0%, but the description thoroughly explains each parameter: email, first_name, last_name, role (with defaults and common values), company_ids, and account_id (auto-resolve). It adds meaning beyond the schema by clarifying default role, accepted values, and behavior of unknown roles.

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 starts with 'Invite a new user' and specifies that CallRail sends an account-creation link. It clearly distinguishes this user creation from sibling tools like delete_user, update_user, and list_users.

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 on when to use the tool (to invite a user) and warns against experimental runs because it sends an email. It does not explicitly compare to alternatives but implies that this is the primary user creation 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?

Discloses soft-delete behavior (status change, record retention) and return shape with no annotation contradiction. Lacks authorization details but sufficient for a soft-delete operation.

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 front-loaded action, efficient use of words. Every sentence adds value: action, behavior, post-deletion guidance, and return format.

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 soft-delete complexity and presence of output schema (implied by return example), the description covers key outcomes, post-action filter, and expected response, making it complete.

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

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

With 0% schema description coverage, the description fails to explain the optional account_id parameter. Only company_id is implied by context. Parameter meaning is incomplete.

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 'Soft-delete a company' with specific outcome 'Status flips to disabled, records retained,' differentiating from hard delete. References sibling delete_tracker semantics for consistency.

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 suggests using list_companies(status='active') to filter after deletion and mirrors delete_tracker semantics, providing clear context for when to use.

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

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

With no annotations provided, the description carries the full behavioral burden. It discloses the destructive outcome ('The rule is gone'), the return format, and the 204 response behavior. It doesn't mention permissions or irreversibility explicitly, but the 'gone' phrasing implies permanence. A small gap but largely transparent.

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 tightly structured: a direct first sentence stating the purpose, a clear alternative, then formatted Args and Returns sections. No redundancy or fluff; every line serves a 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 delete operation, the description covers the essential context: purpose, parameters, return format, and alternative behavior. It also notes the response behavior on 204. Nothing an agent needs to call it correctly is missing.

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

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

Schema description coverage is 0%, so the description must compensate. It explains both parameters: notification_id as the rule ID and account_id with auto-resolution, adding meaning beyond the schema's type/required fields. This fully compensates for the schema gap.

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

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

The description clearly states the verb 'Delete' and the resource 'notification rule', and explicitly contrasts with `update_notification` for muting, making the purpose unambiguous and distinguishing it from the sibling `update_notification`. The phrase 'The rule is gone' reinforces the destructive scope.

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

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

It explicitly provides a when-to-use versus alternative guidance: 'To keep but mute it, prefer update_notification...' and notes that account_id auto-resolves if omitted, giving clear context on when to use this tool over its sibling.

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 of behavioral disclosure. It clearly states the destructive nature ('HARD delete', 'gone permanently'), the side effect on historical applications ('Removes it from any calls or form submissions that had it applied'), and the return value. This is exactly the kind of behavioral context an agent needs for a destructive operation.

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 and front-loaded: the core action and consequence come first, the alternative is stated next, and parameter details are organized in a clear Args/Returns structure. Every sentence earns its place; there is no filler or repetition of schema fields.

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 destructive 2-parameter tool with no annotations, the description covers everything an agent needs: what is deleted, the permanent consequence, the alternative, parameter semantics, and the return format. The output schema exists, so return values are already structured, but the description still adds the concrete JSON example. Nothing critical is missing.

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

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

Schema description coverage is 0%, so the description must compensate, and it does. It explains that tag_id is a numeric integer (not the string-prefixed format used elsewhere), provides a regex pattern, and notes that account_id auto-resolves if omitted. This adds substantial meaning beyond the bare schema, which only lists types and defaults.

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 ('Delete'), a specific resource ('tag definition'), and the scope ('from the account'). It also distinguishes itself from sibling tools like update_tag and create_tag by explaining what it does to the tag and its historical applications. This is a clear, non-tautological purpose statement.

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

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

The description explicitly says when to use this tool vs alternatives: 'To preserve history, prefer renaming or disabling via update_tag instead.' This is a direct, actionable usage guideline that names the alternative and the condition for choosing it. It also warns that this is a HARD delete, which is critical for an agent deciding whether to invoke it.

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

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

No annotations provided, so description fully carries burden. Discloses soft-removal, retained call history, stopped new calls, phone number release, auto-resolve for account_id, and return value structure.

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

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

Well-structured with separate sections for action, args, returns. Some redundancy (e.g., 'An object with' could be trimmed), but each sentence adds value.

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

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

Given output schema exists, description completes the picture with details on soft-removal behavior and edge cases (204 response). Adequate for a delete operation.

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

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

Schema has 0% description coverage. Description adds meaning: tracker_id format 'TRK...' and account_id auto-resolves if omitted. Lacks account_id format details, but overall helpful.

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 'delete (disable) a tracker' with specific verb and resource. Differentiates from sibling tools like create_tracker, update_tracker, and list_trackers by explaining soft-removal semantics.

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 describes the effect of soft-removal and when to use (to disable a tracker). Lacks explicit when-not or alternative tools, but the context is clear enough for an agent to decide.

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 effectively explains the hard-remove nature, immediate loss of access, and return format. It lacks details on permissions or irreversibility, but still provides significant 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 three concise sentences, front-loaded with the core action, then adding behavioral nuance and return format. 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?

Given the tool's simplicity (2 params, no nested objects, output schema example provided), the description covers purpose, behavior, and return format well. Missing parameter explanations, 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 has 0% description coverage, and the description does not clarify the purpose or usage of the two parameters (user_id, account_id) beyond implying account context. No additional meaning is added.

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 'Remove a user from the account' and distinguishes this from sibling delete tools (e.g., delete_company, delete_tracker) by noting the hard-remove behavior versus soft-delete for other entities.

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

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

The description implies usage for permanent user removal but does not explicitly state when to use this tool versus alternatives (e.g., update_user to disable) or provide 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?

With no annotations, the description carries the full burden. It reveals the underlying API endpoint, explains parameter interactions (explicit dates override 'days'), and describes the return format including 'time_zone'. It does not mention authorization or rate limits, but for a read-only aggregation tool this is reasonable.

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: a single line for the purpose followed by a bullet-like list of parameters and return format. Every sentence adds value, and the key endpoint is front-loaded. 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?

Given the simplicity of the tool (5 optional parameters, no output schema provided), the description covers essential behavioral and return details. It explains parameter logic, return fields, and filtering. A minor gap is the lack of explanation on how time_zone is determined, but overall sufficient.

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

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

Schema coverage is 0%, so the description must add meaning to each parameter. It does: 'days' (default 30, ignored if start_date given), 'start_date'/'end_date' (YYYY-MM-DD, explicit overrides), 'company_id' (filter), 'account_id' (auto-resolves). This fully 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 clearly states 'Server-side form-submission totals', indicating it returns aggregate counts. The return format with 'total_results' like '{"total_forms": N}' specifies exactly what the tool computes, distinguishing it from sibling tools like list_form_submissions (which return individual submissions) and get_form_submission (one submission).

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 the parameters but does not explicitly say when to use this tool over alternatives. The return type implies it's for aggregate summaries, but there is no direct comparison to list_form_submissions or other tools for similar purposes. Usage is implied but not clarified.

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, and the description only notes that account_id auto-resolves. It does not disclose potential side effects, permissions, rate limits, or data scope. For a read operation, more transparency about what 'full detail' includes would be helpful.

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 brief parameter list. No fluff, front-loaded with the main action, and every sentence earns its place.

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

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

Given the tool has an output schema (not shown), the description need not explain return format. However, with no annotations, more behavioral context (e.g., uniqueness of call_id, any limitations) would improve completeness.

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

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

Schema coverage is 0%, so description compensates well: specifies call_id prefix format, account_id auto-resolves, and fields are comma-separated extra fields with a reference to list_calls. This adds significant meaning beyond bare 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 'Get full detail for a specific call,' which is a specific verb-resource combination. It distinguishes from siblings like list_calls (list many) and get_call_recording (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 when you need full detail on one call given a call_id, and mentions auto-resolution of account_id. However, it lacks explicit when-not-to-use or alternative tool guidance (e.g., when to use list_calls instead).

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 burden. It discloses that results are paginated, that `account_id` auto-resolves if omitted, and that the return is a JSON string with `page_views[]`. It does not disclose rate limits, whether the data is historical-only, or what happens when no page views exist. The pagination and auto-resolution details add value, but the behavioral profile is incomplete for a read tool with no annotation safety net.

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 and front-loaded: the core purpose is in the first sentence, the pairing context in the second, and the parameter details are in a tight bullet list. Every sentence earns its place; no filler or repetition of schema types.

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 an output schema, so the return structure is already documented. The description adds the pagination semantics, the auto-resolution behavior, and the max page size, which are the non-obvious parts. It is complete enough for an agent to call it correctly, though it could mention whether page views are ordered chronologically or what 'around dialing' means precisely.

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

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

Schema description coverage is 0%, so the description must compensate. It does: it explains `call_id` is a 'CAL...' id, `account_id` auto-resolves if omitted, `per_page` has a max of 250, and `page` is 1-indexed. This adds meaning beyond the raw schema, which only shows types and defaults. The only minor gap is not explaining the default page size behavior beyond the schema default of 100.

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 ('Get'), a specific resource ('visitor's page-view history behind a call'), and the exact content (pages browsed with timestamps before/around dialing). It also names a sibling tool (`call_eligibility_check`) and explains how they pair, which distinguishes it from the many call-related siblings like `get_call`, `get_call_recording`, and `get_call_transcript`.

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 when to use it: for conversion debugging, to see the actual session journey that led to the call. It names the paired sibling (`call_eligibility_check`) but does not explicitly state when NOT to use it or list alternatives for other call data (e.g., `get_call_transcript` for the conversation). Still, the pairing guidance is strong enough to route an 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 at all, the description carries the full burden and handles it well. It discloses the short-lived URL expiration, the account-level prerequisite, the non-retroactive recording behavior, and the empty-url failure mode including user opt-out. This goes well beyond a generic retrieval statement.

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 main purpose is front-loaded in the first sentence, followed by clearly separated Args and Returns sections. Each sentence contributes a distinct useful fact: URL expiration, recording prerequisites, parameter semantics, and return shape. The description is efficient and 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?

For a simple 2-parameter read-oriented tool, the description is nearly complete: it covers input meaning, output shape, expiration, prerequisites, and failure semantics. It does not explicitly compare to sibling tools or discuss authentication, but the output schema and self-contained nature mitigate those gaps.

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

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

Schema description coverage is 0%, so the description must compensate, and it does. It explains that call_id uses a 'CAL...' format and that account_id is the CallRail account ID which auto-resolves when omitted. These details add significant meaning beyond the bare schema properties.

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: 'Get the recording URL for a call.' It clearly centers on the audio recording artifact and a signed URL, distinguishing it from siblings like get_call_transcript and get_call without ambiguity.

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 useful contextual conditions: recording must be enabled, calls before that time have no recording, and empty URLs indicate disabled or opted-out recordings. However, it never explicitly compares to alternatives or states when to prefer this tool over related siblings such as get_call_transcript or get_call, so routing 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?

With no annotations provided, the description carries the full burden of behavioral disclosure. It reveals the dependency on CallScribe, the non-retroactive transcription policy, the 404 behavior under two different conditions, the error envelope hint, and the exact return structure (JSON with segments, confidence scores, durations). This is exceptionally transparent and helps the agent handle failures gracefully.

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 with clear sections (Args, Returns, warning). Every sentence contributes essential information—prerequisites, error semantics, parameter hints, return format—with no filler. The warning is appropriately highlighted with a date and a clear explanation of the 404 meaning. It is long but earns its length.

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 a 2-parameter tool with a complex operational context (feature flags, API changes, ambiguous error codes), the description covers all necessary aspects: when to use, what to expect, error interpretation, and return structure. It even notes the output schema details (segments, confidence, durations) despite having an output schema, making it self-contained. Nothing an agent needs to call and interpret this tool is missing.

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

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

The schema provides zero description coverage, so the description must explain the parameters. It does: call_id is given a format hint ('CAL...' id) and account_id is described as auto-resolving if omitted. This adds real semantic value beyond the bare type definitions and prevents misuse.

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 ('Get the AI transcript for a call'), immediately distinguishing it from related sibling tools like get_call_recording or call_summary. The purpose is unambiguous and leaves no question about what the tool returns.

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 the prerequisites (CallScribe enabled at the time of call, Premium Conversation Intelligence as of a specific date) and explains the critical 404 ambiguity, telling the agent when the tool will not work. This goes beyond vague guidance and gives clear operational constraints.

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 of behavioral disclosure. It goes beyond a generic read by revealing a non-obvious edge case: soft-deleted companies return a disabled record instead of a 404, and instructs the agent to check the status field. This is precisely the kind of behavioral gotcha that prevents incorrect 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?

The description is compact and well-structured: a one-line purpose, an Args block, and a focused behavioral note. Every sentence contributes and the critical edge-case note is clearly separated.

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 existence of an output schema, the description need not enumerate return fields. It covers what the tool does, both parameter semantics, and the one significant behavioral exception (disabled records), making it sufficient for correct invocation and response interpretation.

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

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

Schema descriptions are absent, but the description compensates by documenting both parameters: company_id is identified as a 'COM...' id and account_id is explained as auto-resolving when omitted. This adds real semantic value beyond the bare types and titles 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 opens with a specific verb and resource: 'Get full detail for one company.' The singular scope clearly distinguishes it from list_companies and other company operations, so an agent can identify it as the per-record detail lookup.

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

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

It provides clear context for usage: when you need full detail for a single company. It does not explicitly name alternatives or state when not to use it, such as recommending list_companies for multiple companies, but the singular framing makes the intended use reasonably unambiguous.

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 carries the full behavioral burden. It discloses that the tool returns a JSON string and enumerates key returned fields, including the `form_data` dict, and explains the optional behavior of `account_id` auto-resolving. However, it does not mention not-found or error behavior, which would make it more complete.

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 and front-loaded: a one-sentence purpose, a usage context sentence, then compact Args and Returns sections. Every sentence adds value, and there is no filler 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 two-parameter retrieval tool, the description covers what the tool does, when to use it, how the parameters behave, and what the response contains. Although an output schema exists, the description's return-value details make it self-sufficient; no critical calling information is missing.

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

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

The input schema has no property descriptions (0% coverage), but the description fully compensates: it documents `submission_id` as a 'FOR...' id and explains that `account_id` is a CallRail account ID that auto-resolves if omitted. This adds essential semantic meaning beyond the bare type declarations.

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 and resource ('Get full detail for one form submission') and immediately distinguishes it from list-style operations by emphasizing 'one' submission and 'all submitted field data.' It also references `list_form_submissions`, making the differentiation from its closest sibling explicit.

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

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

The description provides clear usage context: fetch a single submission after seeing a submission ID via `list_form_submissions` or in a webhook callback. It does not explicitly state 'use list_form_submissions when you need multiple submissions,' but the single-vs-list distinction is strongly 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?

No annotations are provided, and the description only says 'full detail,' implying a safe read. It does not disclose any behavioral traits such as permissions, rate limits, or side effects, which is minimal for a tool with no 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 concise with two sentences and a brief args list. Every sentence adds useful information, and the purpose 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 the presence of an output schema (not shown), the description does not need to explain return values. It provides essential usage details, though a minor inconsistency (numeric id vs string schema) exists.

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 coverage, the description adds meaning by specifying that integration_id is numeric and from list_integrations, and that account_id is optional and auto-resolves. This adds value beyond the bare 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 'Get full detail for one integration,' which is a specific verb+resource. It distinguishes from sibling tools like list_integrations and other get_* 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 tells the agent to use integration_id from list_integrations and notes that account_id auto-resolves, providing context on when to use each parameter. However, it does not explicitly state when not to use the tool 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?

With no annotations, the description carries full responsibility and does so thoroughly: it reveals cross-channel aggregation, first-touch/last-touch attribution, pagination behavior (page and per_page with max 250), account_id auto-resolution, and the exact return structure (JSON string with lead and timeline). This goes well beyond what the schema or annotations would tell 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 front-loaded with the core purpose, then provides a short motivation, followed by a compact, structured Args list and a Returns section. Every sentence adds useful information; there is no filler or repetition of schema 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 definition covers all four parameters, return shape, pagination semantics, and the source of the key identifier. It also explains why the tool exists relative to the manual alternative, which gives an agent enough context to select and invoke it correctly without needing additional documentation.

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%, yet the description compensates fully. It tells the agent that lead_id is the 'PER...' id from list_leads, that account_id auto-resolves when omitted, that per_page is the timeline page size with a 250 maximum, and that page is 1-indexed. This adds meaning far beyond the bare type declarations.

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 ('Get a lead's full cross-channel activity timeline') and immediately enumerates the exact data types included: calls, form submissions, and text threads. It also distinguishes itself from sibling tools by explicitly stating it replaces the manual 'search calls by number + search forms by email' 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 states a clear use case: reconstructing a customer's history across channels, and names the alternative manual approach it replaces. It does not, however, explicitly list when not to use it or compare it to other sibling tools like list_calls or list_form_submissions beyond the one replacement note.

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 bears full burden. It specifies the returned fields and auto-resolution for account_id. It implies read-only behavior by saying 'Get', which is adequate. Could mention idempotency or side effects, but not needed for a get tool.

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

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

The description is two sentences plus a brief Args list. It is concise, front-loaded with purpose, and every sentence adds value.

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

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

Given the output schema exists, the description need not detail returns. It covers purpose, parameter usage, and sibling distinction. Complete for a straightforward get 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%, but the description explains both parameters: thread_id comes from `list_sms_threads` and account_id auto-resolves if omitted. This adds necessary context beyond the minimal 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 retrieves a lead-management record for an SMS thread (notes, value, tags, lead_qualification, state). It explicitly distinguishes from the sibling tool `get_text_message` by directing users to that tool for message transcripts.

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 exactly when to use this tool (to get lead-management record) and when not to (for message transcripts, use `get_text_message`). This provides clear context and an alternative.

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, and the description only states 'Get full detail' which implies a read operation but does not explicitly disclose behavioral traits like idempotence, side effects, permissions, or rate limits. The description carries the full burden but adds minimal 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 extremely concise with no superfluous words. It uses a clear structure: a single sentence for purpose followed by a terse bullet list of arguments. 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?

For a simple get-by-ID tool with an output schema, the description is minimally sufficient. However, it lacks any mention of preconditions (e.g., tag must exist), error scenarios, or how the returned 'full detail' relates to the output schema. The context is somewhat incomplete.

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 value beyond the schema by noting that 'tag_id' is numeric (schema says string) and 'account_id' auto-resolves if omitted. However, it does not fully compensate for the 0% schema description coverage, missing details on valid values or format.

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 'Get full detail for one tag.', specifying the verb 'get' and the resource 'tag' with scope 'one'. This distinguishes it from sibling tools like list_tags (list all), create_tag, update_tag, and delete_tag.

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

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

No guidance is provided on when to use this tool versus alternatives such as list_tags for retrieving all tags. The description simply describes the action without usage context.

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

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

With no annotations, the description discloses that the tool returns full conversation details including all messages. It explains the conversation_id parameter format. However, it does not mention any potential side effects or limitations, but as a read operation this is adequate.

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

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

The description is extremely concise, with two clear sentences for purpose followed by a structured Args section. Every sentence adds value with no repetition or filler.

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

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

Given the presence of an output schema, the description does not need to detail return values. It is complete for a 'get' operation, but the missing explanation of account_id slightly reduces completeness. Overall, it adequately covers the tool's functionality.

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

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

Schema description coverage is 0%, so the description must explain parameters. It only describes conversation_id (with example) but omits account_id entirely, leaving its purpose unclear. This is a significant gap.

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

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

The description clearly states the action ('Get') and the resource ('full detail for one SMS conversation, including all messages'). It distinguishes from sibling tools like list_text_messages by specifying retrieval of a single conversation with full detail.

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 full detail of a single conversation is needed. It does not explicitly state when not to use or mention alternatives, but the context of 'Get' vs 'List' is clear from the name and 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?

No annotations exist, so the description must disclose behavior. It mentions 'full detail' and auto-resolution of account_id, but fails to explain what data is returned, any permissions needed, or whether it's read-only. The phrase 'full detail' 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?

The description is very concise, with a clear purpose followed by parameter notes. It front-loads the main action, though the argument format could be more 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 existence of an output schema, the description is mostly adequate for a simple read tool. However, it lacks usage guidance and does not fully explain what 'full detail' covers, leaving some ambiguity.

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 value beyond the schema by noting tracker_id format ('TRK...' id) and account_id auto-resolution. However, schema coverage is 0%, so more detail would be beneficial; no mention of account_id's default null 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 'Get full detail for a specific tracker,' specifying the action and resource. It distinguishes from sibling tools like list_trackers, create_tracker, update_tracker, and delete_tracker.

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

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

The description provides no guidance on when to use this tool versus alternatives like list_trackers or update_tracker. It does not specify prerequisites or context for use.

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

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

With no annotations, the description carries the full burden and discloses key behavior: it returns a 'JSON string' and enumerates the fields, including the 'accepted_at' null-if-pending and role enum semantics. It also notes account_id auto-resolves if omitted, which goes beyond the schema. However, it does not explicitly state whether the operation has side effects or requires particular permissions; this would have been useful but the read-only nature of 'get' reduces the gap.

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

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

The description is compact and well-organized into a short opening sentence, Args, and Returns sections. Every sentence adds essential information: the main purpose, both parameter meanings, and the return shape. There is no fluff or repeated information, making it 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 that the output schema exists (so return structure is already declared) and the tool only takes two simple parameters, the description is actually richer than needed by also listing exact response fields. It leaves no obvious gaps for correctly invoking the tool: it explains what the tool does, the parameters, and the response format.

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

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

Even though schema description coverage is 0%, the description fully compensates. user_id is explained with its 'USR...' format, and account_id is described with its default behavior, 'Auto-resolves if omitted'. Both parameters get meaningful semantic information beyond the raw type definitions, which is especially important given the lack of 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 'Get' and resource 'one user', explicitly scoping to 'full detail' for a single user on the account. This clearly separates it from list_users and other user-related siblings, giving the agent an unambiguous understanding of what this tool does.

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 returns 'full detail for one user on the account', which implies it should be used when a single user's complete record is needed. It does not explicitly mention list_users as an alternative, but the 'one user' scope provides clear context, which is a well-defined 'when to use' signal even without an explicit exclusion.

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 carries full responsibility. It accurately portrays the read-only nature of listing accounts and explains the output's significance. While it doesn't cover edge cases or rate limits, it is transparent about the core 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 extremely concise (two sentences) yet fully informative. The first sentence states the primary purpose immediately, and the second adds essential context. Every word contributes 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?

Given the tool has no parameters and an output schema exists (as indicated by context signals), the description is complete. It explains what the tool does and why the output matters, leaving no critical gaps for an agent to select or 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?

The input schema has 0 parameters, and schema description coverage is 100%. Per guidelines, a tool with no parameters receives a baseline of 4. The description does not need to add parameter-level detail 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 is specific: 'List CallRail accounts accessible to this API key.' It clearly identifies the action (list), the resource (accounts), and the scope (accessible to this API key). It also explains the critical role of the returned `id` field, distinguishing this tool from other list tools such as list_companies or list_calls.

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 about typical usage ('Most users have one account per agency') and hints that it is a prerequisite for other tools via the auto-resolved account_id. However, it does not explicitly state when to use or avoid this tool, nor does it compare it directly to 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 present, the description fully discloses important behaviors: pagination, default values (days=7, end_date=today), the client-side filtering of `source` and its impact on `total_records`/`total_pages`, the deprecated `answered` parameter and its mapping, and the fact that `source` is not a server-side filter, so results may be unfiltered if used incorrectly. This is transparent about edge cases.

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 structured with a clear overview and a detailed args list, but it is lengthy due to the extensive parameter documentation. The key points are front-loaded, and the detail is necessary given the lack of schema descriptions, but it could be tightened by removing some redundancy in the `fields` example list. Still, it is well-organized and readable.

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

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

The description is highly complete for a complex tool with 11 parameters and an output schema. It covers parameter behavior, defaults, edge cases, and even directs to alternative tools for better functionality (e.g., `call_stats` for source breakdowns). The output schema presumably covers the response format, so nothing essential is missing for an agent to call 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?

The input schema has 0% coverage (no descriptions within the schema), so the tool description must fully document each parameter. It does so comprehensively: explains `account_id` auto-resolution, `days` lookback, `start_date`/`end_date` formats, `answer_status` server-side filter, `answered` deprecation, `source` client-side behavior, `per_page` max, `page` 1-indexed, and `fields` comma-separated list with examples. This goes well 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 indicates the tool lists calls, with explicit mention of pagination and filterable parameters (company, date window, answer status). It stands out from siblings like get_call (which retrieves a single call) and search_calls_by_number, providing a distinct purpose of listing many calls with filters.

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 usage guidance: explains that `days` is ignored if `start_date` is provided, that `source` is applied client-side and explains its limitations, and that `answered` is deprecated in favor of `answer_status`. It also clarifies when to use `call_stats(group_by='source')` for source breakdowns, offering alternative routing.

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 carries the full behavioral burden and handles it well. It discloses default filtering behavior, pagination semantics, the 250-item limit, the meaning of 'active' (excludes disabled/soft-deleted), and the previously missing ability to fetch page 2. This is strong transparency for a list operation.

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, front-loaded with the core operation, and followed by a clear Args block. Every sentence adds value, including the brief historical note about page 2, which clarifies an important capability without padding.

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?

All optional parameters are documented with defaults and edge cases, and the output schema exists to cover return values. For a simple listing tool, the description leaves no significant operational detail missing.

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

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

The input schema has 0% description coverage, leaving the parameters otherwise opaque. The Args block compensates by explaining all four parameters: account_id auto-resolution, per_page maximum, status values/defaults, and page indexing/pagination 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 opening sentence states a specific verb and resource: 'List companies (client businesses) under a CallRail account.' This clearly distinguishes the tool from list_accounts, list_trackers, and other listing siblings by identifying the exact entity type and scope.

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

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

The description gives clear invocation context: account_id auto-resolves, per_page has a documented max, status has defined defaults, and page is explicitly needed when an agency has more companies than per_page. It does not name alternative tools or explicit when-not-to-use cases, but provides solid situational guidance for the parameters.

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 carries full burden. It discloses pagination, filtering, default values, and return format. It also notes that account_id auto-resolves. This is transparent for a list operation.

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 with an Args section and Returns section. It is slightly long but each sentence serves a purpose. Could be trimmed slightly but remains 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 8 parameters (0 required) and an output schema, the description thoroughly covers pagination, filtering defaults, and return structure. It is complete for an agent to use without ambiguity.

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?

Despite 0% schema description coverage, the description explains each parameter's meaning, defaults, and behavior (e.g., days ignored if start_date provided, account_id auto-resolves, fields list). This adds substantial value beyond the input 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 'List form submissions captured by CallRail's Form Tracking,' which is a specific verb and resource. It distinguishes from siblings like get_form_submission (singular) and create_form_submission.

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

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

The description mentions pagination and filtering but does not explicitly tell when to use this tool versus alternatives like get_form_submission or create_form_submission. Usage context 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?

No annotations are present, so the description carries the full transparency burden. It discloses the 400 error without company_id, the account-level limitation, auto-resolution of account_id, and pagination semantics, all of which go beyond the schema.

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

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

Two compact sections: one scoping sentence and a terse Args list. No filler, and the most decision-critical information (required company_id) is front and prominent.

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 straightforward list operation with an output schema and no nested objects, the description supplies everything needed to call it correctly: required argument, failure mode, pagination behavior, and account resolution. Nothing essential is missing.

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

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

Schema description coverage is 0%, so the description must document parameters, and it covers all four. company_id gets a format ('COM...'), requiredness rationale, and failure mode; per_page and page get limits/indexing; account_id gets fallback 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?

States a specific verb and resource: 'List integrations attached to one company,' with concrete examples (GMB, Google Ads, Facebook, Slack, Webhooks). The one-company scope and explicit exclusion of account-level listing clearly distinguish it from broader sibling list 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?

Provides clear operational context: the endpoint is company-scoped, account-level listing is not supported, and company_id is mandatory. It doesn't name a specific alternative tool for account-level needs, but the scope guidance is strong enough to prevent misuse.

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 carries the full behavioral burden. It does well by disclosing that leads are deduplicated across channels, that account_id auto-resolves when omitted, that per_page is capped at 250, and by describing the exact response shape and lead fields. It does not mention auth requirements or ordering, but for a read/list operation the disclosed behavior is substantial.

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 organized with an intro, a clarifying concept sentence, an Args block, and a Returns block. Each section earns its place, and the key defining trait (deduplicated person record) is front-loaded. No filler or redundant restatement of the tool name.

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

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

For a list tool with four optional parameters and no annotations, the description is remarkably complete: it defines the resource, explains the deduplication behavior, documents every parameter, specifies pagination constraints, and lists the return fields. There is no obvious missing information an agent would need 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 0%, so the description must compensate for the bare schema. It does: account_id 'auto-resolves if omitted,' company_id 'filter to one company,' per_page 'page size (max 250),' and page '1-indexed.' This adds real semantic value beyond the parameter names and defaults.

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: 'List leads (unique people) across calls, forms, and texts.' It then defines a lead as CallRail's deduplicated person record, which clearly distinguishes this tool from raw call, form, and text listers among the siblings. The mention of get_lead_timeline for cross-channel history further sharpens the tool's identity.

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 list_leads returns and explicitly points to get_lead_timeline when a lead's full history is needed, providing a clear alternative. It does not exhaustively enumerate when not to use the tool versus list_calls, list_form_submissions, or list_text_messages, but the deduplication framing makes the intended use case 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?

No annotations provided. Discloses pagination details (page size, index) and auto-resolution behavior but does not mention read-only nature, auth requirements, or error 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?

Structured with bullet-like listing of parameters. While not overly long, the 'Args:' prefix adds minimal value. Could be slightly more 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 presence of an output schema, the description adequately covers parameters and pagination. Lacks context about what a notification rule is or authentication prerequisites.

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%, but the description fully explains each parameter's purpose and behavior (e.g., optional filters, page size max, page index, auto-resolution).

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 lists notification rules on the account, and mentions optional filters. It is specific but does not explicitly differentiate from sibling list 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?

Provides context for optional filters and auto-resolution of account_id, but no guidance on when to use this tool versus alternatives like other list 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?

With no annotations, the description carries the full burden. It signals a read-like operation by listing, and it documents pagination (`per_page` max 250, page 1-indexed) and auto-resolution of `account_id`. It also indicates the return type is per JSON string, which is useful. It stops short of explicitly stating the operation is read-only, but the verb and mention of an update separate centrally-con noted the distinction.

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 organized into a main purpose sentence, a short argument list, and a return section. The opening contrast with a sibling tool is front-loaded and efficient. The block format is easy to parse, though it is a bit long because of the every-parameter details. Overall, each 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?

The description fully specifies how to call the tool, what each parameter means, and what will be returned (the full shape of each `sms_thread`). It covers pagination, auto-resolution, and the distinction from a sibling, leaving no critical gap for an agent 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 0%, but the description provides meaningful semantics for every parameter: `account_id` auto-resolver, `company_id` filters to a company, `per_page` page size and max 250, `page` 1-indexed. This goes far beyond the bare property titles and fully compensates for the schema's lack of 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 starts with 'List SMS threads' — a clear verb-product pair — and immediately distinguishes from `list_text_messages` by noting the latter returns conversation transcripts while threads carry the lead-management surface (notes, value, tags, lead_qualification, state). This lets an agent pick the correct listing tool without inspecting schemas.

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 contrasts with `list_text_messages` and mentions that threads are updatable via `update_sms_thread`, giving context for when to use this list and when not. It does not mention `get_sms_thread` for fetching a single thread, so the guidance is strong but not exhaustive.

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 cover behavior. It only states the basic operation without mentioning pagination, rate limits, or what happens with empty results. The read-only nature is implied but not confirmed.

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

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

The description is very concise at one sentence, but it sacrifices critical information for brevity. It lacks structure (e.g., front-loading the most important usage context) and omits necessary details.

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 4 parameters, 0% schema coverage, and no annotations, the description should fully describe behavior and parameters. It only covers the company filter, leaving pagination and account scope undocumented. Output schema exists but is not referenced.

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 0%, so the description must explain all parameters. It only mentions company_id (filter), ignoring page, per_page, and account_id. This leaves 3 of 4 parameters 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 lists all tags, optionally filtered to one company. It distinguishes from sibling tools like get_tag (single tag) and create/delete/update tags.

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

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

The description indicates when to use it (list all tags or filter by company) but lacks explicit when-not or alternative tools. The sibling context helps, but the description alone is insufficient for clear decision-making.

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 covers pagination, auto-resolution of account_id, date window behavior, and return format. It notes potential 403 errors for missing A2P permission, but lacks explicit read-only declaration or rate limits.

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

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

Well-structured with clear one-liner, organized Args and Returns sections. Every sentence adds value; no fluff or repetition.

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

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

For a tool with 7 parameters and output schema, the description covers pagination, filtering, and permission notes. Could include more edge cases (e.g., empty results) or detailed conversation structure, but adequate overall.

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%, but the description fully documents all 7 parameters, including defaults, format, and behavior (e.g., days ignored if start_date provided). Adds significant semantic value beyond schema.

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

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

The description clearly states it lists SMS/text message conversations via CallRail trackers, with pagination and filtering. It distinguishes from siblings like get_text_message (single message) and list_calls (calls).

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 (listing messages) and mentions prerequisites (A2P permission for outbound) and references create_text_message for more info. It does not explicitly name alternatives 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?

No annotations are provided, so the description carries full burden. It discloses key behaviors: status default returns all including soft-deleted/disabled, account_id auto-resolves. However, it does not mention pagination behavior beyond page size, permission requirements, or whether it's a read-only operation (though implied).

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 a brief introduction followed by a parameter list. It avoids fluff, but the parameter list could be more structured (e.g., using bullet points). Every sentence adds value.

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

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

Given the tool's simplicity and the presence of an output schema (not shown but indicated), the description covers essential aspects: what the tool does, parameter semantics, and key defaults. It does not explain return format, but the output schema handles that. Minor gaps include lack of usage guidelines and more detailed behavioral 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 description must compensate. It adds significant meaning: account_id auto-resolves if omitted, company_id filters to one company, per_page max size 250, page 1-indexed, status defaults to None with common values 'active' and 'disabled'. This greatly aids 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 lists tracking phone numbers (trackers) and explains what a tracker is. It uses specific verb 'list' and resource 'trackers', distinguishing it from siblings like get_tracker (single) and create_tracker (create).

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

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

The description does not explicitly state when to use this tool vs alternatives. It implies usage when you need a list of trackers, but lacks guidance on when to use list_trackers versus get_tracker or create_tracker. No exclusions or alternatives are mentioned.

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