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

No annotations provided, so description fully discloses behavior: reads current tags, merges, PUTs; auto-creates tags; silently filters whitespace entries; drops non-strings with warning; de-duplicates; max 100 tags; errors if no valid tags remain.

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 sections, front-loaded with main purpose. Could be slightly more concise but all sentences add 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?

Covers all aspects: behavior, usage, parameters, return value (JSON string with updated call), error conditions (no valid tags). Complete for a tool with 3 params and no annotations.

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

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

Schema coverage is 0%, but description compensates fully: explains call_id format, tags must be strings (non-strings dropped), de-duplication, max 100, and account_id auto-resolves. Provides meaning 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 appends tags without replacing, using 'Append tags to a call WITHOUT replacing existing ones.' It distinguishes from sibling tools like update_call and remove_call_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?

Explicitly tells when to use (add labels without losing prior tags) and when not to (use update_call to replace tags). Also explains auto-creation of company-level tags and filtering behavior.

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 thoroughly discloses safety features (dry_run default, 500-cap limit, filter requirement), performance characteristics (extra GET when `set_tags_add` is used), and return values for both dry_run and commit modes. This is comprehensive behavioral disclosure.

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 sections for purpose, safety, arguments, returns, and performance notes. It is front-loaded with the key purpose and examples. While comprehensive, it could be slightly more concise; the performance note is valuable but adds 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 10 parameters, no annotations, and presence of an output schema, the description is remarkably complete. It covers input requirements, behavioral details (safety, performance, default behaviors), and output formats for both dry_run and commit scenarios. The output schema existence is noted but the description still explains return values, which is helpful.

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?

Input schema coverage is 0%, so the description fully compensates. It explains every parameter: filter fields (company_id, days, source, answered) with same semantics as `list_calls`, requirement of at least one, set_* fields with their effects (add vs replace), `dry_run` default, and `account_id` auto-resolution. This adds significant meaning beyond the schema.

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

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

The description clearly states the tool's purpose: applying the same update to every call matching a filter. It provides concrete examples like 'tag every Bing call this month as low-priority' and explicitly distinguishes it from sequential `update_call` invocations, making the purpose unambiguous and differentiating it from siblings.

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

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

The description explicitly explains when to use this tool (bulk updates matching a filter) and contrasts it with alternatives (replaces dozens of sequential `update_call` invocations). It also provides guidance such as requiring at least one filter to avoid 'update everything ever' and the default `dry_run=True` for safety.

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 responsibility for behavioral disclosure. It comprehensively explains the four checks, auto-resolution of account_id, configurable duration threshold, and the nuanced source detection logic. This fully informs the agent of the tool's 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 moderately long but well-structured with a summary, bulleted checks, and arg explanations. It is efficient and front-loaded. Could potentially be slightly more concise, but it earns its length with valuable information.

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

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

Given the tool's complexity (multiple checks, configurable parameters, and a verdict output), the description covers all essential aspects: purpose, criteria, parameter details, auto-resolution, and a summary of the return value. It is complete for effective agent usage.

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: explains call_id as the required identifier, account_id auto-resolves if omitted, and google_ads_min_duration_seconds defaults to 60 with guidance on when to override. This adds substantial meaning beyond the schema.

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

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

The description clearly states the tool's function: auditing whether a call is eligible to count as a Google Ads conversion. It specifies the action ('audit'), resource ('call'), and context ('Google Ads conversion eligibility'). This effectively distinguishes it from sibling tools, which are mostly CRUD operations or other utilities.

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 use case: 'where did my conversion go' debugging. It details the checks performed but does not explicitly mention when not to use or provide alternatives. However, the purpose is specific enough that usage 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?

Without annotations, the description effectively explains the tool's server-side nature and contrasts with call_summary. It details return format and parameter behavior. However, it could be more explicit about potential limitations (e.g., max days, result size) and 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 a first-line summary, usage context, parameter list, and return format. It is concise but could be slightly tightened in parameter explanations. Overall, effective and efficient.

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

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

Given the presence of an output schema in the description, detailed parameter semantics, and differentiation from siblings, the description is contextually complete. Minor gaps like error handling or edge cases are acceptable, as the tool is well covered.

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 fully compensates by explaining each parameter: group_by options, days default, start_date/end_date precedence, company_id filtering, fields as comma-separated metrics with default, and account_id auto-resolution. This adds significant meaning beyond the schema.

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

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

The description clearly states the tool performs server-side call aggregation via a specific API endpoint, and explicitly distinguishes it from the sibling tool 'call_summary' (client-side pagination). This meets the highest standard of specificity and differentiation.

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: 'prefer this over `call_summary` when you only need grouped totals', and notes when `call_summary` remains useful. This provides clear context and 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?

Since no annotations exist, the description carries full burden. It discloses the risk of paginating the entire account history without a window and implies the tool is read-only via 'summarize' and 'returns counts'. Missing explicit mention of auth requirements or side effects, but these are negligible for a summary 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 extremely concise: two sentences plus a note, each sentence earning its place. The purpose is front-loaded, followed by return values, use case, and a critical behavioral note. No superfluous content.

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

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

Given 5 parameters, zero schema description coverage, and presence of an output schema, the description adequately covers the date window constraint and the tool's role as a summary. However, it omits explanation of account_id and company_id parameters, which could cause confusion in multi-account contexts.

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 'days' and 'start_date' and their constraint, but does not mention 'account_id', 'company_id', or 'end_date'. This leaves 3 out of 5 parameters undocumented; baseline 3 is appropriate as the description adds partial guidance.

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

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

The description clearly states 'Summarize calls over a date window' and enumerates the returned aggregates (total, answered/missed, etc.), distinguishing it from sibling tools like list_calls that return individual call records.

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 positions the tool for 'weekly/monthly rollups without pulling every call into context' and warns about the requirement for a time window (days>=1 or start_date). Could be improved by explicitly contrasting with alternatives (e.g., 'for individual call details, use list_calls').

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 transparency burden. It explains the data source and return format but does not disclose constraints like rate limits, authentication requirements, or whether the tool is strictly read-only. The behavioral disclosure is adequate but not comprehensive.

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

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

The description is highly concise: a single sentence for purpose followed by a structured list of arguments. Every sentence adds value, and the format is easy to scan.

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

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

The description covers the tool's purpose, all parameters, and the return structure (JSON with total_results and data[]). Given the output schema exists, further detail on return values is not needed. Minor gaps exist regarding error handling and edge cases, but overall it is sufficiently complete for a query 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?

Given 0% schema description coverage, the description compensates well by explaining each parameter in the Args section, including defaults and interaction rules. It could be improved by detailing accepted values for fields and the format for company_id/account_id.

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 per-day call volume using a specific API endpoint, with a daily trend line instead of client-side bucketing. It uniquely distinguishes itself from siblings like call_stats and list_calls by specifying the output is an aggregated time series.

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

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

The description provides explicit parameter guidance, such as the default for days and the precedence rules between days and start_date. However, it lacks direct comparison to sibling tools like call_stats or compare_periods to help the agent decide when to use this specific 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?

No annotations, so description carries full burden. It discloses implementation detail (one tool call, historical tracker limits) and clarifies which deltas are accurate, which is excellent transparency.

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

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

Concise yet comprehensive, with clear sections (purpose, use cases, args, returns, implementation). No superfluous content.

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

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

Given output schema existence, description still covers return breakdown clearly. Fully informs agent of what to expect and caveats, making it highly complete.

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

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

Schema coverage is 0%, but description richly documents both parameters: days (default, cap, typo warning) and account_id (auto-resolve), adding critical context beyond the schema.

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

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

Purpose is extremely clear: compare current vs previous N-day window with per-company and agency-wide metrics. Specific verbs and resource, distinct from all sibling tools.

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

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

Provides explicit use cases like detecting growth or invoice surprises, but does not state when to avoid using it or mention alternatives, though none exist among siblings.

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

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

With no annotations, the description fully discloses behavior: creation is free, boolean parameters inherit account defaults unless explicitly set, and warns that sending 'False' on paid features would disable them. This prevents accidental misconfiguration.

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 a header, usage paragraph, and bulletized parameter list. Slightly verbose on redundant notes (e.g., billing statement could be in general context), but 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?

Covers all 9 parameters, required vs optional, default behavior, and usage nuances. No additional information needed for correct invocation; output schema is available, so return values are not required.

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 coverage, the description explains each parameter in detail: acceptable values (e.g., time zone examples), defaults, and the critical None vs False distinction. This 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?

Description opens with 'Create a new company (client) under the account' – a specific verb+resource pairing. It distinguishes from siblings like 'delete_company' and 'update_company' and contrasts billing with 'create_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?

Explicitly states 'Useful for new-client onboarding' and compares with 'create_tracker' for cost context. Provides default reasoning but lacks explicit when-not-to-use guidance.

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

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

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, the description fully discloses behavior: dialing sequence, costs, legal implications, and the safety mechanism. It leaves no ambiguity about the tool's effects.

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

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

The description is well-organized with warnings, arg docs, and return value. While slightly lengthy, every sentence is informative and 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's complexity (real-world dialing, legal risks, 5 parameters) and an output schema present, the description covers all essential usage and behavioral aspects comprehensively.

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 (from_number, to_number, confirm_dialing, company_id, account_id) with format, defaults, and required behavior, compensating fully for the schema deficiency.

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 places an outbound call that actually dials a real phone. It is distinct from sibling tools like get_call 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?

It provides strong guidance on when to use (place outbound calls) and includes a safety guard (confirm_dialing=True). It warns about legal compliance and misuse, though it doesn't explicitly contrast with alternative tools.

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

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

No annotations are provided, and the description does not disclose behavioral traits beyond basic creation. It does not mention reversibility, idempotency, rate limits, or what happens if a duplicate name is used.

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 block and front-loaded purpose. It is slightly verbose but every sentence adds value, making it effective while not overly 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 that an output schema exists, the description does not need to explain return values. It covers the purpose and all parameters adequately, making it complete for a creation 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?

Despite 0% schema description coverage, the description adds significant meaning: it explains the name, company_id requirement, auto-resolution of account_id, and details the color parameter with a list of valid options and default value. This 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 clearly states 'Create a new tag scoped to one company.' This is a specific verb+resource combination that distinguishes itself from sibling tools like update_tag, delete_tag, and list_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?

No explicit guidance on when to use this tool versus alternatives. It mentions that tags are per-company and company_id is required, but does not explain when to use create_tag vs update_tag or add_call_tags.

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 cost implications and pricing in detail, which is critical for a billing-related tool. No annotations provided, so description carries full burden; covers major behavioral aspects.

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 warning, pricing, and parameter list, though slightly long due to 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?

Covers all aspects: costs, required parameters, logic for different types, and return value hinted. Output schema exists, so returning details are handled.

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, description compensates fully, explaining all 14 parameters, including defaults, valid values, and auto-resolution for account_id.

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 'Create a new tracking phone number (tracker)' and distinguishes from sibling tools like delete_tracker and update_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?

Provides explicit guidance on required confirm_billing=True and when to use type='source' vs 'session', but does not compare to other creation 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 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?

Describes the destructive action ('rule is gone') and return value. While no annotations are provided, the description adds context about permanence, but could more explicitly mention irreversibility or permissions.

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

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

Front-loaded purpose, then alternative, then parameter docs, then return. Every sentence earns its place with no wasted words.

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

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

Covers all essentials: purpose, alternative, parameters, return value. With no annotations, the description fully compensates, and the presence of output schema is covered by the return description.

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 description adds meaning for both parameters: explains account_id auto-resolves and notification_id is the rule ID. Could include more constraints (e.g., format) but sufficient for use.

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 'Delete a notification rule' with a specific verb and resource. It distinguishes from siblings like update_notification by providing an alternative.

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

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

Explicitly tells when to use this tool vs. the alternative: 'to keep but mute it, prefer update_notification(send_email=False, send_desktop=False, send_push=False)'.

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 full behavioral transparency burden. It explicitly states 'HARD delete' and that the tag is gone permanently along with historical applications, disclosing the destructive nature. It also mentions the return format.

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

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

The description is concise with two paragraphs plus Args/Returns. Front-loaded key action and warning. 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 parameters, no nested objects, output schema exists), the description covers all necessary aspects: purpose, usage guidance, behavioral warnings, parameter details, and return value. It is fully complete.

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

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

Schema description coverage is 0%, but the description adds detailed meaning for both parameters: explains tag_id format (numeric, integer, regex constraint) and that account_id auto-resolves if omitted. This goes beyond the schema type definitions.

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 'tag definition', and explains the effect of removing it from calls and form submissions. It distinguishes from siblings by explicitly mentioning 'update_tag' as an alternative for preserving history.

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

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

The description provides explicit guidance: it notes that deletion is permanent and advises using 'update_tag' instead to preserve history. This gives clear when-to-use and when-not-to-use 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?

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 exist, so the description carries full burden. It discloses that the tool returns page views with timestamps, is paginated, and that account_id auto-resolves. It does not mention auth or rate limits, but for a read-only tool the disclosure 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 concise: two short paragraphs with front-loaded purpose and clear parameter list. 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?

The description covers purpose, paired usage, all parameters with semantics, return format (JSON string with page_views[]), and pagination. Given the output schema exists and the tool is straightforward, this is fully complete.

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

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

The input schema has 0% description coverage, but the tool's description includes a dedicated 'Args' section that explains each parameter: call_id format, account_id auto-resolution, per_page max, and page indexing. This adds significant meaning beyond the schema.

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

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

The description clearly states the tool retrieves 'visitor's page-view history behind a call' with timestamps, distinguishing it from siblings like call_eligibility_check. The verb 'Get' is specific and the resource is well-defined.

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 pairs this tool with call_eligibility_check for conversion debugging, providing a clear usage context. It does not mention explicit alternatives or when-not-to-use, but the context strongly implies it is the go-to tool for pre-call browsing analysis.

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

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

With no annotations, the description fully discloses behavioral traits: URL expiration, prerequisite of recording being enabled, no retroactive recording, and meaning of empty URL. This exceeds expectations.

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?

Description is succinct with a clear intro, prerequisites, args, and returns. Every sentence adds value; no redundancy.

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

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

Covers all necessary aspects: purpose, prerequisites, parameter details, return format, and edge cases. Given the tool's complexity, the description is fully 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?

Despite 0% schema description coverage, the description adds meaning by specifying call_id format ('CAL...') and explaining account_id auto-resolves. The Returns section also clarifies output structure, compensating for the schema gaps.

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

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

The description clearly states 'Get the recording URL for a call' and elaborates on the short-lived URL, distinguishing it from sibling tools like get_call or 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?

Provides clear context on when to use the tool (need recording URL), including prerequisites (recording enabled) and edge cases (calls before enablement have no recording). Does not explicitly list alternatives or when not to use, but the context is sufficiently 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 provided, so description carries full burden. Discloses that transcripts are not retroactive, that a 404 has multiple causes, and that account_id auto-resolves. Does not mention rate limits or other potential issues, but for a read operation the key behaviors are 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?

Description is front-loaded with purpose, then prerequisites, then parameter details, then return value. Every sentence adds value, though the warning about a specific date (2026-05-21) may become outdated. Still 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?

With 2 parameters fully described, an output schema present (though not shown), and a clear description of the return format (JSON with segments, confidence scores, durations), the description provides sufficient context for the agent to use the tool correctly.

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

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

Schema coverage is 0%, but description fully explains both parameters: call_id (format 'CAL...') and account_id (auto-resolves if omitted). Adds significant meaning beyond the bare schema, making invocation easier.

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 'Get the AI transcript for a call' – a specific verb and resource. Distinguishes from sibling tools like get_call_recording (recording vs transcript) and get_call (call details). No 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?

Explicitly mentions prerequisites (CallScribe enabled at call time, Premium subscription) and explains failure modes (404 may mean no transcript or plan limitation). While it does not list alternatives, the context of transcript retrieval is well-defined.

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, so description carries full burden. Discloses that soft-deleted companies return a record with disabled status instead of 404, and account_id auto-resolves. This is key behavioral information.

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?

Extremely concise: one-line purpose, bullet-pointed args, and a note. No redundant sentences. Front-loaded and 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 an output schema exists (not shown), description doesn't need to detail return values. It covers the essential behavior including soft-delete handling. Could mention error cases, but overall sufficient for a simple 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 has 0% description coverage. The description adds 'COM...' id format for company_id and 'Auto-resolves if omitted' for account_id, both beyond schema details.

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 'Get full detail for one company', which is specific and distinct from sibling tools like list_companies. The note about disabled records adds further specificity.

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 like auto-resolution of account_id and behavior for soft-deleted companies, but does not offer explicit guidance on when to use vs. alternatives like list_companies.

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 implies a read-only retrieval operation but does not explicitly state that it has no side effects or require specific authentication. The return description provides some behavioral context but lacks full transparency on constraints.

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 clear purpose statement and structured Args/Returns sections. It avoids unnecessary detail but includes essential guidance. It is well-organized and front-loaded.

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

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

Given the simple input schema (2 parameters, 1 required) and presence of an output schema, the description adequately covers the return value contents (submitted_at, customer details, etc.). It does not explain every nested field but is sufficient for an agent to understand what data will be returned.

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 adds crucial meaning: it explains the format of submission_id ('FOR...' id) and that account_id is optional and auto-resolves. This goes beyond the bare schema and helps the agent understand parameter values.

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 full details for one form submission, including all submitted field data. It distinguishes from sibling tools like list_form_submissions (for listing IDs) and update_form_submission (for modification), providing a specific verb and resource.

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

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

The description explicitly suggests use after seeing a submission ID via list_form_submissions or a webhook callback, giving clear context. While it does not explicitly state when not to use, the guidance is sufficient for an agent to decide between this and similar 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 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?

No annotations are provided, so the description carries the full burden. It explains that the tool returns a JSON string with lead record and timeline array, pagination info, and that account_id auto-resolves. It does not explicitly state read-only behavior, but the description implies no side effects. A score of 4 is appropriate given good coverage without 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 well-structured: main purpose, benefit, args block, and returns. It is informative but slightly verbose; the args block could be more formal. Still, it is front-loaded with key information 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?

With 4 parameters, 1 required, no schema descriptions, and an output schema present (though not shown), the description covers all parameters, explains output structure, and mentions pagination. It is complete for the tool's complexity and does not need to detail return values due to output schema.

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

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

The description adds significant meaning beyond the input schema: it explains lead_id format ('PER...' lead id from `list_leads`), account_id auto-resolves if omitted, per_page max 250, and page is 1-indexed. Since schema description coverage is 0%, the description fully compensates, providing format constraints and behavior.

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

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

The description clearly states the tool's purpose: 'Get a lead's full cross-channel activity timeline — every call, form submission, and text thread from that person in one response, with first-touch/last-touch attribution.' It distinguishes from siblings by explicitly mentioning it replaces the manual multi-step search process.

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

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

The description explicitly tells when to use the tool: 'This replaces the manual "search calls by number + search forms by email" dance when reconstructing a customer's history.' It provides clear context for use but does not include explicit when-not-to-use or alternative tools beyond the implied replacement.

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?

No annotations provided, so description carries full burden. It describes the return JSON fields and behavior of account_id auto-resolve, but does not disclose error conditions, rate limits, or idempotency.

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?

Description is concise with Args/Returns structure. However, it redundantly lists return fields that are already in the output schema, adding slight verbosity.

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

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

For a simple get tool with two parameters and no annotations, the description covers purpose, parameter details, and return structure. Missing error handling info, but overall adequate.

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

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

Schema description coverage is 0%, so description adds necessary meaning. It explains user_id format ('USR...' id) and account_id auto-resolve behavior, which goes beyond the raw 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 user on the account,' which uses a specific verb and resource. It distinguishes from sibling tools like list_users and update_user.

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

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

No explicit guidance on when to use this tool vs alternatives. It implies use for a single user by ID, but does not mention when not to use it or suggest list_users for multiple users.

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 must carry the full burden of behavioral disclosure. It only states the basic action without mentioning read-only nature, authentication requirements, rate limits, or any side effects.

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

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

The description is very short and has a clear structure with an Args list. It is concise but at the expense of completeness, earning a high score for lack of waste.

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 2 parameters and an output schema, the description lacks explanation for account_id and does not provide any context about the return value or pagination, making it 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?

Schema description coverage is 0%, so the description must add meaning. It describes webhook_id as 'Webhook id (CallRail-assigned)' but does not mention account_id at all, leaving that parameter undocumented.

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 'Get' and the resource 'full detail for one webhook subscription,' which distinguishes it from sibling tool 'list_webhooks.' However, the phrase 'full detail' is somewhat vague.

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 like list_webhooks. There are no prerequisites, exclusions, or contextual hints.

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?

No annotations are provided, so the description carries the burden. It discloses pagination and parameter behaviors (e.g., auto-resolution of account_id, ignoring days if start_date provided). However, it does not mention rate limits, result ordering, or what happens on empty results, leaving some ambiguity.

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

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

The description is front-loaded with the main purpose and then provides a clear bullet-like list for each parameter. It is slightly verbose but well-organized, earning its length with useful 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 10 parameters and no schema coverage, the description covers all parameters adequately. An output schema exists (not shown), so return value details are less needed. However, it lacks mention of result ordering or limits beyond per_page, and no context on typical use cases.

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 compensate. It does so thoroughly: explains each parameter (e.g., days default 7, ignored if start_date; date format YYYY-MM-DD; source examples; answered 'true'/'false'; per_page max 250; page 1-indexed; fields comma-separated with examples; account_id auto-resolves; company_id filter). This adds significant meaning beyond the schema.

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

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

The description clearly states 'List calls' with pagination and filtering options, distinguishing it from sibling tools like get_call or search_calls_by_number. It provides specific filterable attributes (company, date window, source, answered status).

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

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

The description implies usage for listing and filtering calls but does not explicitly state when to use this tool vs alternatives like get_call for a single call or compare_periods for period comparisons. No when-not guidance is given.

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

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

No annotations are provided, so the description bears the full burden of disclosure. It explains important behavioral traits: account_id auto-resolution, pagination behavior (1-indexed pages, page size limit), and status filtering. This exceeds minimal requirements for a list 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-structured with a clear first sentence and an Args block. It is concise but includes necessary details. The historical note about pagination adds context without excessive verbosity.

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

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

Given the tool's simplicity (4 optional parameters, no required params) and the presence of an output schema, the description is complete. It covers all parameters, pagination, and filtering. The only minor gap is the lack of mention of the number of results returned, but the output schema likely covers that.

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

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

The input schema has 0% description coverage, leaving the description to explain all 4 parameters. The description does so effectively: account_id auto-resolves, per_page max 250, status values explained, page is 1-indexed and necessary for pagination. This adds significant value beyond the schema's type/default information.

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

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

The description clearly states the tool's purpose: 'List companies (client businesses) under a CallRail account.' It uses a specific verb (List) and resource (companies), and distinguishes itself from sibling list tools (e.g., list_accounts, list_calls) by specifying the resource type.

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

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

The description provides context for when to use the tool (listing companies under an account) and gives pragmatic guidance on pagination for agencies with many companies (page parameter). It does not explicitly state when not to use it or list alternatives, but the sibling tools are distinct enough that confusion is unlikely.

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

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

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 provided, so the description carries the full burden. It discloses that company_id is required and account_id auto-resolves, but lacks details on error handling, rate limits, or the exact behavior when parameters are invalid.

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 uses a clear docstring format with Args section, is front-loaded with purpose, and contains minimal redundancy (only the '**Required**' is slightly redundant). It is concise given the number of parameters.

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 an output schema exists, the description need not detail return values. It covers the required parameter and pagination, but lacks explanation of the account_id resolution logic and potential error conditions.

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 adds significant value: it explains company_id format, per_page max (250), page indexing (1-indexed), and account_id auto-resolution, going beyond the schema.

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

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

The description clearly states the tool lists integrations for a company, listing specific examples (GMB, Google Ads, etc.), and distinguishes it from siblings like get_integration (singular) and list_companies (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 emphasizes that company_id is required and account_id auto-resolves, but does not provide explicit guidance on when to use this tool versus alternatives or when not to use it.

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

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

Discloses that account_id auto-resolves, per_page max 250, page is 1-indexed, and returns details. No annotations exist, so description carries burden; lacks rate limits or auth notes, but acceptable for a list 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?

Structured with clear first sentence, explanation, alternative, bullet-point args, and return format. No wasted words.

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

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

Covers all parameters and output structure; lacks pagination iteration details but sufficient given output schema description.

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

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

Adds meaning beyond schema: account_id auto-resolves, company_id filters, per_page max, page indexing. Schema coverage 0%, so description compensates well.

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

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

Clearly states 'List leads (unique people)', explains what a lead is (deduplicated person record), and distinguishes from sibling tools like get_lead_timeline and 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?

Explicitly suggests using get_lead_timeline for full history, but could provide more guidance on when to filter by account_id vs company_id or pagination usage.

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 explains the output format and notes that `account_id` auto-resolves, but does not mention other behaviors like rate limits, authentication, or safety profile. It is adequate but not exhaustive.

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

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

The description is concise, front-loads the core purpose, contrasts with a sibling, and lists parameters in a structured args block. Every sentence adds value; no redundancy.

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

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

Given the tool has an output schema and four simple parameters, the description covers purpose, differences, all parameters, and return format. Minor omissions like sorting order or total count do not hinder usability.

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, but the description compensates by providing clear, human-readable explanations for all four parameters, including defaults and constraints like 'max 250' for per_page.

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 SMS threads' and distinguishes from sibling tool `list_text_messages` by noting that threads carry lead-management fields and are updatable, making the purpose specific and unambiguous.

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

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

The description explicitly contrasts with `list_text_messages` and explains what threads contain, providing clear context for when to use this tool. It does not include explicit when-not-to-use statements but the contrast suffices for 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?

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.