KaiCalls

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

Annotations already declare readOnly, idempotent, non-destructive, and closed-world, so the safety profile is fully covered. The description adds nothing beyond restating that it is a check by ID—no mention of what status values mean, latency, or whether it errors on unknown IDs. With annotations carrying most of the burden, the added behavioral value is minimal.

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

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

A single front-loaded sentence with no filler. It is efficient; the terseness is more of a completeness issue than a structural one.

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

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

With an output schema, full parameter coverage, and rich annotations, the description only needs to orient the agent—which it does. However, it omits sibling differentiation and any hint about interpreting status results, leaving it minimally adequate rather than 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?

Only one parameter, and schema coverage is 100% with its own description ('The call ID to check'). The description repeats that it is keyed by ID but adds no format, source, or example guidance. Baseline 3 is appropriate given the schema does the work.

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

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

States a specific verb and resource: check the status of a call, keyed by ID. Clear enough that an agent knows what it returns in kind. It does not distinguish itself from nearby siblings such as get_call_recording, get_transcript, or list_recent_calls, which keeps it from a 5.

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?

Usage is only implied: use it when you have a call_id and need that call's status. No explicit when-to-use, when-not-to-use, or named alternative (e.g., list_recent_calls to find a call ID first) 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?

Annotations already declare readOnly/idempotent/non-destructive, but the description adds genuinely non-obvious behavior: it discloses that missing entitlement, incomplete setup, or stale sessions do not authorize a call, that the tool 'cannot assert or advance proof', and that a completed private test is independent of customer-route coverage and forwarding. These are semantic result caveats an agent could not obtain from the annotations or schema.

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

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

Five front-loaded sentences with no filler; the scope statement comes first and the caveats follow. Density is high and some phrasing ('coherent assigned number', 'persisted private-test proof') costs readability, but each sentence carries distinct information rather than restating the name.

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

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

An output schema exists, so return values need not be explained, and the annotations cover the safety profile. The description supplies the authorization preconditions and the interpretation caveats an agent needs; only the sibling differentiation and any hint about what happens when preconditions fail (empty vs. error) are missing.

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

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

Schema description coverage is 100% and all five parameters are documented in the schema, including the conditional optionality of business_id and the rejection of superseded/foreign session IDs. The description adds nothing parameter-specific beyond the phrase 'one accessible business', so baseline 3 applies.

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

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

The description names a specific verb ('Read') and a specific compound resource: current call readiness plus persisted private-test proof for one business. It is clearly not a generic status or analytics read, but it never names or contrasts with the nearest sibling (check_call_status), so an agent must infer the boundary from the phrase 'activation'.

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?

Usage is implied through preconditions ('only a currently entitled owner with a coherent assigned number'), which tells the agent what state the business must be in for a meaningful answer. However, there is no explicit when-to-use/when-not-to-use statement and no routing to alternatives like check_call_status or get_business_info, which is the main gap for a status-reading tool sitting among several status readers.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false and openWorldHint=false, so safety and side-effect behavior need no restatement. The description adds the useful fact that the output is pre-aggregated metrics rather than raw records, but says nothing about freshness/caching, computation window semantics beyond 'recent', or cost, so the added value is modest.

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?

One tightly packed sentence that front-loads the verb and resource, then uses a parenthetical to enumerate returned metrics. The metric list is dense but each item earns its place by telling the agent what questions this tool can answer; no filler or redundancy.

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

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

An output schema exists, so return-value explanation is not required, and the sole parameter plus all four annotations are covered structurally. What remains missing is only the routing guidance against sibling listing tools, which is a minor gap for a zero-required-parameter read-only 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 100% and the single 'days' parameter is fully documented there with default 30 and max 90, so the schema does the heavy lifting. The description's phrase 'recent time window' gestures at the same concept but adds no syntax or boundary information beyond it; baseline 3 applies.

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

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

Specific verb ('Get') plus a clearly named resource ('dashboard summary') with an enumerated payload (lead counts by status, conversion rate, call volume/duration, top agents, business outcomes by type) and a stated scope ('recent time window'). This is distinguishable from the sibling list_*/get_* tools, which return raw entities rather than aggregates, though the description never names a sibling to make the contrast explicit.

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

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

Usage is only implied: an agent can infer this is the tool for aggregate/overview questions and that list_leads or list_recent_calls are for row-level data, but the description never says when to prefer this over those alternatives or what question types it is meant to answer. No exclusions or prerequisites are given.

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

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

Annotations already declare readOnly, idempotent, non-destructive, closed-world behavior, so the bar is lower. The description still adds real value by enumerating what gets read back (profile, agent count, call volume) and by disclosing a behavioral detail annotations cannot capture: the response may contain a `next_step` pointer to a setup 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?

Three short sentences, front-loaded with what the tool returns before explaining the diagnostic purpose and the forward path. Slightly indirect phrasing ('This shows whether a business number that answers missed calls already exists') costs a little, but nothing is padding.

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

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

Output schema exists and annotations cover the safety profile, so the description needn't explain return values — and it still previews the main fields. With one fully documented optional param, an agent has enough to call this correctly; only the comparison against granular siblings is left implicit.

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

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

Schema coverage is 100% and the single optional `business_id` parameter is documented in the schema with its default-to-first-accessible-business behavior. The description says nothing about the parameter, so baseline 3 applies — the structured field carries this dimension entirely.

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

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

States a specific verb and resource bundle: reads back profile details, agent count, and recent call volume for a business. That scope distinguishes it from single-purpose siblings like list_agents or get_analytics, though the description never names those alternatives to make the contrast explicit.

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

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

Gives a concrete decision context — use it to determine whether a business number that answers missed calls already exists — and routes the agent forward when that condition fails via the `next_step` field. It stops short of stating when to prefer this over the granular siblings, so no exclusions are offered.

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

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

Annotations already declare this is a read-only, idempotent, non-destructive operation. The description adds that it returns a real recording URL for audio playback, but does not disclose practical details such as URL expiration, authentication requirements, or whether recordings may be missing for some calls.

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

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

The description is a single, well-structured sentence with no wasted language. The purpose and primary value are 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 one-parameter read operation, existing annotations, and an output schema, the description is largely complete. It could be improved by noting recording availability or URL freshness, but the core intent is clear.

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?

There is only one parameter, call_id, and the schema description coverage is 100%, so the schema already fully documents it. The description adds no further parameter-level semantics, which is acceptable given the high schema coverage baseline.

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

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

States a specific verb and resource: getting the real call recording URL for a call. It also distinguishes the output from transcript data by emphasizing voice/audio, which differentiates it from the sibling get_transcript tool.

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

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

The description gives a clear usage context: reviewers should use it to listen to audio instead of relying only on the transcript. It implies the alternative (transcript) but does not explicitly state when not to use this tool, such as if a recording is unavailable.

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

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

Annotations already cover read-only, idempotent, non-destructive safety, so the bar is lower; the description still adds real value by naming the backing table (admin_change_history), enumerating what mutations are captured (update_agent_config, business rules, phone secretary, dashboard), and stating that every entry is reversible via rollback_config.

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

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

A single dense sentence, front-loaded with the verb and resource, followed by field list and provenance. The aside about the voice tool is slightly decorative but supports the provenance claim, so it earns most of its place.

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

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

With an output schema present, return-value detail is optional, and the description still names the key fields. Combined with full schema coverage and annotations, nothing essential is missing, though a note on ordering/recency window would close the last gap.

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

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

Schema coverage is 100% and both parameters (agent_id, limit with default 20 / max 100) are fully documented in the schema. The description adds no parameter-level meaning such as ordering or time-window semantics, so baseline 3 applies.

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

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

States a specific verb and resource ('List an agent's recent config-change audit trail') and enumerates the record's fields, so the agent knows exactly what comes back. It does not, however, distinguish itself from the overlapping sibling list_config_versions, which an agent may confuse with this audit trail.

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?

Usage is only implied: 'Every mutation KaiCalls makes to an agent ... is logged here' tells the agent what will be found, and the rollback_config mention hints at a follow-up action. There is no explicit when-to-use/when-not guidance and no comparison against list_config_versions.

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

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and a closed-world scope, so the safety profile is fully covered. The description adds only that the response carries a score and its explanation, which the output schema likely already conveys, and says nothing about not-found 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?

One front-loaded sentence naming the resource, the lookup key, and the payload, with no redundant restatement of the title. Nothing to trim.

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

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

With an output schema present, return values need no elaboration, and annotations cover safety; the only residual gap is error behavior for an invalid or missing lead ID. For a one-parameter read tool the description is essentially 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 100% with a single documented parameter ('The lead ID to fetch'), and the description's 'by ID' adds no format or sourcing detail beyond that. Baseline 3 applies since the schema does the work.

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

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

States a specific verb and resource ('Get full details for a single lead by ID') and adds what comes back (AI lead score plus explanation). The singular, ID-based framing implicitly separates it from list_leads, though no sibling is named explicitly.

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?

Usage is only implied: an agent can infer this is the detail-fetch for one lead versus list_leads for enumeration, but the description never states when to prefer it or what to do when the ID is unknown. No explicit alternatives or preconditions are given.

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

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

Beyond the annotations, the description adds meaningful operational context: manager-account access requirements, inclusive date semantics, a 30-minute source lag, and metric definitions for connected calls and responsiveness. It also clarifies what the report is not, reducing misuse risk.

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

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

The description is dense and front-loaded: the first sentence establishes the core operation, followed by access requirements, date semantics, freshness, metric definitions, and exclusions. Every sentence adds useful information without 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?

Given the output schema and annotations, the description covers the most important behavioral and domain context: access prerequisites, date inclusivity, data lag, metric definitions, and exclusions. It remains slightly incomplete because it does not clarify the two ID parameters or explicitly route against the closest sibling 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%, so the description must carry parameter meaning. It adds important semantics for start_date and end_date by stating they are calendar dates inclusive at both ends, but it does not explain business_id or connection_id, leaving two required parameters under-specified.

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

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

The description states a specific verb and resource: reading the live Google Local Services aggregate account report, including spend, currency, and charged lead totals. It also distinguishes the scope from signed-case revenue and lead-rating reporting. It does not explicitly name the closest sibling, get_lsa_report, so sibling differentiation is present but not fully explicit.

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

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

The description implies when the tool is appropriate by stating it requires linked manager-account access and by excluding signed-case revenue and lead-rating reporting. However, it does not explicitly say when to use this tool versus get_lsa_report or other LSA-related siblings, leaving routing partly to inference.

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

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

Annotations already declare readOnly, idempotent, non-destructive, so the safety profile is covered. The description adds two pieces of real context not in annotations: a hard cap of the latest 200 events and the freshness caveat that history is only as current as the last sync — an agent needs both to interpret the result correctly.

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 short sentences, zero filler, with the scope and the 200-event cap front-loaded and the sync-freshness caveat second. Every clause carries information an agent would otherwise lack.

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

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

The tool has an output schema, so return shape needn't be described, and annotations cover the safety profile. The description covers the remaining essentials: result cap, scope to one lead, and data-staleness semantics. Nothing needed to call it correctly is missing.

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

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

Schema description coverage is 0%, so the description must compensate; it only implies lead_id via 'for an LSA lead' and says nothing about business_id or the relationship between the two UUIDs. The parameter names are largely self-describing, so the gap is small, but it is not fully closed.

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

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

States a specific verb and resource ('Read the latest 200 synced Google LSA conversation events for an LSA lead') and scopes it to a single lead, which separates it from report/account-level siblings like get_lsa_report and get_lsa_account_report. It stops short of naming a sibling as an alternative, but the resource is unambiguous.

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

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

The phrase 'for an LSA lead' implies usage when you have a lead_id and need its conversation history, but the description never states when to prefer this over get_lead, list_lsa_leads, or get_lsa_report, nor any preconditions (e.g. the lead must be synced). Usage is only inferable.

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

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

Annotations already declare readOnly, idempotent, closed-world and non-destructive, so the safety bar is low. The description still adds real value beyond them: it discloses that sync freshness and completeness are included, that removed unrated leads are counted separately, and that certain metrics cannot be derived from counts — preventing a downstream agent from misreading totals.

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?

Four sentences, front-loaded with what the report contains, followed by scoping, caveats and exclusions. Dense but every sentence carries information; the final sentence on unavailable metrics is slightly long but earns its place by preempting a common misread.

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?

An output schema exists, so return-shape detail is not required, and the description still explains the interpretive caveats (separate counting of removed unrated leads, freshness/completeness fields). The only shortfall is that business_id and the relationship to other LSA tools remain unaddressed.

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 carry the load. It does clarify the two date parameters precisely — start inclusive, end exclusive, UTC — which is meaningful semantics absent from the schema. business_id (uuid) receives no explanation, leaving one of three parameters 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 opens with a specific verb-and-resource statement — lead counts, types, statuses, ratings and credit counts — scoped to an explicit UTC window. That is far more informative than the title 'get lsa report'. It does not, however, contrast itself with near siblings like get_lsa_account_report or list_lsa_leads, so an agent must infer the boundary.

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?

Usage is implied by the scoping language ('for an explicit UTC window') and by the exclusions: financial amounts, signed cases and response-time metrics are unavailable here. That signals when to look elsewhere, but no sibling tool is named and no explicit 'use this instead of X' routing is provided.

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

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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive), and the description still adds non-obvious behavioral context: that returned configuration is a saved record and does not evidence a live workflow. The scope disclaimer about cloud-project access further prevents misreading the result. It stops short of describing pagination or latency, but the substantive caveats are present.

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 short sentences with no filler, front-loaded with what is inspected. Slightly telegraphic phrasing ('saved configuration never proves a live workflow') costs a little readability, but nothing is redundant.

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?

An output schema exists, so return values need not be explained, and the safety profile is annotation-covered. What is missing is the one thing only the description can supply: what the required business_id means, and how to choose this tool over get_lsa_account_report. Adequate but with a clear gap.

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

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

Schema description coverage is 0% and the single required parameter 'business_id' (uuid) is never mentioned in the description. The rule is that at low coverage the description must compensate, and here it does not — an agent gets no guidance on which business identifier form to supply or what happens if the business has no LSA setup.

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?

Names a specific verb ('Inspect') and resource ('Google LSA account selection and sync freshness') plus an included deliverable ('setup steps'). It is distinguishable from the reporting siblings (get_lsa_report, get_lsa_account_report), though it never states that contrast explicitly so the boundary is inferred from the word 'setup'.

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 sentence 'Saved configuration never proves a live workflow' hints at a caution condition and 'Cloud-project production access is not shown here' carves out a scope exclusion. However, the exclusion points at an external system (Google Cloud), not at a sibling tool, so no alternative is actually named and no positive 'use this when…' trigger 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?

Annotations already carry the read-only, idempotent, closed-world safety profile, so the description's job is to add what they can't: newest-first ordering, the exact payload of the single-meeting mode (live status, minutes used, summary), and the bonus plan-level remaining-minutes figure. The one gap is that list mode gives no hint about result caps or pagination.

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

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

A single front-loaded sentence that covers both modes, ordering, returned fields and the REST equivalent, with no filler. The 'Mirrors GET /api/v1/meetings' clause is compact and useful for developers tracing behavior.

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

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

With an output schema present, the description needn't enumerate return values yet does so anyway for the single-meeting case. The only shortfall for a list-capable tool is the absence of any statement about how many meetings come back or how to page through them.

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

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

Schema coverage is 100%, so the baseline is 3; the description earns a bump by clarifying what 'id' buys you — not just a record but live status, minutes used and summary — which goes beyond the schema's terse 'omit to list recent meetings'. business_id is left entirely to the schema, which is fine at full coverage.

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

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

States a specific verb and resource ('List the meetings Kai was sent into') plus an explicit second mode ('or one meeting by id') with the fields returned. No sibling tool covers meetings, and the dual list/single shape is unambiguous from the first clause.

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 mode selection is spelled out in the schema and echoed in the description: omit id to list newest-first, supply id to fetch one meeting with status/minutes/summary. It does not name exclusions or alternatives, but the sibling set contains no competing meeting tool, so there is little ambiguity to resolve.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, openWorldHint=false and destructiveHint=false, so the safety profile is fully covered elsewhere. The description contributes the useful detail that this returns live account configuration state (alert routing, escalation, per-agent voice/model/greeting), but says nothing about permissions needed, freshness of 'live' data, or result size.

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?

One front-loaded sentence that leads with the verb and scope before the payload enumeration; every clause is substantive. It is dense but not padded, with only a mild cost in reading 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?

With an output schema present, return values need no explanation, and only one optional parameter exists at full schema coverage. The description adequately frames what domain the returned configuration covers, leaving only the when-to-use decision undocumented.

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

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

Schema coverage is 100% for the single parameter, so the default-to-first-business behavior is already documented in structured form. The description's references to 'business-level' and 'live account' reinforce the scope but add no syntax or format detail beyond the schema, making 3 the appropriate baseline.

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 names a specific verb ('Read') and a precisely scoped resource ('business-level operational setup of a live account'), then enumerates the exact contents (alert recipients, alert flags, escalation rules, send-link entries, agent voice/model/greeting metadata). This content list effectively separates it from nearby siblings like get_business_info, get_lsa_setup and list_agents, though no sibling is named explicitly.

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

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

There is no guidance on when to call this versus alternatives such as get_business_info, get_lsa_setup or list_agents, and no stated preconditions or exclusions. The only usage-shaped hint is the schema's note that business_id defaults to the first accessible business, which is not in the description.

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

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint=false, so the safety profile is fully covered. The description contributes the useful constraint that transcripts exist only for completed calls, but says nothing about what happens on a live/not-found call.

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?

One short sentence, front-loaded with the verb and resource, no filler or repetition of the title.

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 one-parameter read tool with full annotations and an output schema, the definition is nearly sufficient. The remaining gap is behavior for non-completed or unknown calls, which nothing else covers.

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

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

Schema coverage is 100% with a single required call_id fully documented, so the description adds nothing parameter-wise. Baseline 3 applies when the schema carries the semantics.

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

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

States a specific verb and resource ('get the transcript and summary of a completed call'), and the mention of 'summary' adds a detail beyond the name. It does not explicitly differentiate itself from the closest sibling (get_call_recording), so it falls short of a 5.

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

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

The phrase 'completed call' implies a precondition, but the description never states when to use this versus get_call_recording or check_call_status, nor what to do if the call is still in progress. No alternatives or exclusions are named.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true and destructiveHint=false, and the description's read-only claims largely restate that. It does add genuinely new behavioral context: missing or stale standing is computed but not persisted, no notifications are sent, and badge progress does not itself raise call or text caps — a non-obvious caveat an agent would otherwise get wrong.

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 scope statement is front-loaded and every sentence carries operational content, with no filler. The first sentence is a long chain of clauses that would read better as a list, but nothing is wasted.

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

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

An output schema exists, so return shape need not be explained. For a read-only, three-parameter tool with full schema coverage, the description covers scope, mode routing, persistence behavior, and the sibling relationship — nothing an agent needs is missing.

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

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

Schema coverage is 100% and the enum description for focus already spells out all four modes, so most of the description's focus explanations are redundant restatement. The one real addition is the caveat that badge progress does not establish higher caps, which clarifies what the 'outbound' view does and does not imply — enough to edge above pure repetition but still baseline territory.

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

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

States a specific verb and resource ('Read one business's KaiCalls trust level') and enumerates the exact value space (Sprout, Verified, Trusted, Pro, Partner) plus what is returned: current level, next steps, unlocks, outbound usage against limits, and holds. It is clearly distinguishable from recheck_trust_level, which is named as the recompute-and-save counterpart.

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?

Gives explicit routing by focus mode ('ladder' explains every level; 'level' with level explains one) and names the alternative tool with its selecting condition: use recheck_trust_level to recompute and save, this one to read without saving. It also rules out an impossible use case up front ('Levels are earned, never set: no tool can raise one').

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

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

Annotations already establish readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is fully covered structurally. The description adds the scoping detail that results are limited to the authenticated account's agents, but says nothing about default result counts, pagination behavior, or cost, which are left to the schema.

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

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

Two short sentences with no filler, and the core action is front-loaded before the clarifying detail. Slightly spare rather than padded, which suits a simple list tool.

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

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

An output schema exists and all three parameters are documented, so the description does not need to explain return values or argument formats. For a read-only list tool with full annotation coverage, only the missing explicit usage guidance keeps this below 5.

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

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

Schema description coverage is 100%, so limit, offset, and business_id are already fully documented in the schema, including defaults and bounds. The description adds no parameter meaning beyond that, making the baseline 3 correct.

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

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

States a specific verb and resource ('List the KaiCalls agents') scoped to 'the authenticated account'. The second sentence clarifies what the listing reveals (whether a secretary is already answering calls), which helps an agent distinguish it from sibling list_* tools, though it never names those siblings explicitly.

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 mention of 'whether this business already has a secretary answering its calls' implies a setup/onboarding use case, but there is no explicit when-to-use guidance, no prerequisites, and no named alternative such as get_business_info or get_activation_status. Usage is inferable rather than stated.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false and openWorldHint=false, so the safety profile is fully covered. The description adds only the tenant-scoping context; it says nothing about result ordering, pagination behavior, or empty-result 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?

A single front-loaded sentence with zero waste and the scope stated up front. It is efficient, though so terse that there is little structure to speak of.

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?

Output schema exists and annotations are rich, so the return and safety story need no explanation. However, for a listing tool with a free-form status filter and no enums, the description leaves the agent without guidance on valid status values or paging expectations.

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

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

Schema description coverage is 100%, so limit, offset, and status are already documented with defaults and bounds. The description adds no extra meaning — notably it does not enumerate valid status values, which the schema leaves as a free string with no enum.

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?

Specific verb ('List') plus resource ('outbound call campaigns') with an ownership scope ('authenticated business'). It is clearly distinct from siblings like list_leads or list_agents by resource name, though it does not explicitly acknowledge those 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?

No when-to-use guidance, no prerequisites, and no mention of alternatives (e.g., when to use list_recent_calls vs this). The only usage signal is the implicit 'authenticated business' scoping.

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

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

Annotations already declare readOnly, idempotent, non-destructive, closed-world, so the safety profile is covered. The description still earns credit by disclosing that all returned config data is hashed and redacted (i.e. no raw secrets or prompt content) and that rollback lineage is included — neither of which is derivable from annotations. Pagination beyond the schema's `limit` is not discussed.

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 tight sentences, front-loaded with the listing behavior and followed by the mode switch — an agent can parse the decision in one read. Minor waste: 'redacted' appears in both sentences, and the trailing REST-endpoint mirror adds little for an agent that has no HTTP context.

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

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

With an output schema present, return values need no prose, and the annotations carry the safety semantics. The description covers both operating modes and the nature of the data returned. Remaining gap is small: nothing explains how version_number values are ordered or what configuration items the history actually captures.

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

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

Schema description coverage is 100%, so the baseline is 3. The description largely restates the schema's own wording for `version` (per-version fetch returning a redacted config_snapshot); its only incremental signal is the 'hashed, redacted' framing, which is marginal on top of what the schema already provides.

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

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

States a specific verb and resource — 'List an agent's hashed, redacted assistant config version history' — plus a distinguishing qualifier ('rollback lineage included'). The 'Mirrors GET /api/v1/agents/versions' grounding makes the scope unambiguous. It does not, however, differentiate itself from plausible siblings like get_change_history or get_operational_settings, so it stops short of a 5.

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 dual mode is spelled out explicitly: 'Pass `version` to fetch one version's full redacted config_snapshot instead of the list,' with the schema adding 'omit to list.' That gives the agent a clear decision rule for the branch. Missing is any guidance on preconditions (permissions/trust level) or when this is preferable to the change-history sibling.

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

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

Annotations already declare readOnlyHint, idempotentHint, non-destructive, and closed-world behavior, so the description does not need to repeat safety traits. It adds useful context by stating that results are scoped to the authenticated business and that the latest AI lead score is included when available. It does not mention pagination behavior or ordering, but the annotations carry the main behavioral burden.

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, zero waste, and the core purpose and scoping are front-loaded. The second sentence adds useful return-value context without bloating the definition.

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?

An output schema exists, so the description need not explain return values, and it appropriately mentions the notable AI lead score field. Annotations cover the safety profile. The only minor gap is that sibling differentiation is not explicit, but the definition is otherwise complete for selecting and invoking the tool.

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

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

Schema description coverage is 100%, so the schema already documents all five parameters, including limits, offsets, and filter fields. The description names the filter categories but adds no syntax, allowed values, or interaction rules beyond what the schema provides. Baseline 3 is appropriate when the schema does the heavy lifting.

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 gives a specific verb and resource ("List leads") and clarifies scope ("for the authenticated business"). It also notes optional filters and that AI lead scores are included, which helps distinguish it from a raw envelope. However, it does not explicitly differentiate this from siblings like get_lead or list_lsa_leads, so an agent must infer the boundary.

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

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

The description implies usage by mentioning optional status/source/agent filters, but it gives no explicit guidance on when to use this tool versus get_lead (single lead) or list_lsa_leads (LSA-specific leads). The context is clear enough for basic selection but not for confident routing among similar siblings.

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

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

Annotations already declare readOnly, idempotent, non-destructive, closed-world behavior, so the safety profile is covered elsewhere. The description adds real context beyond that: what fields come back (charge and credit states, source IDs, ratings) and the important distinction between the LSA lead id and the CRM lead_id, which the annotations cannot convey.

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 dense sentences with the purpose front-loaded and the ID-disambiguation note immediately after. Nothing is padded, though the second sentence only matters at consumption time and could have been paired with pagination guidance instead of standing alone.

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?

An output schema exists, so return-format explanation is not owed. However, for a three-parameter listing tool with zero schema descriptions, the description should at least say that business_id scopes the results and that limit/offset paginate them; that gap leaves an agent guessing about call shape.

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

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

Schema description coverage is 0%, so the description carries the burden of explaining business_id, limit, and offset — and it says nothing about any of them. Pagination semantics (limit max 100, offset max 100000) and the required UUID business_id, which presumably scopes the entire listing, are undocumented in both places.

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 names a specific verb and resource — listing synced Google LSA leads — and enumerates what the listing carries (charge/credit states, source IDs, rating details), which separates it from the generic list_leads sibling. It never names the sibling explicitly, but 'synced Google LSA leads' is a concrete enough scope for an agent to distinguish it.

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 LSA framing implies when this tool applies versus generic lead tools, and the note that the LSA lead id is what LSA commands consume versus lead_id linking to the CRM is genuinely useful routing information. There is still no explicit when-to-use/when-not statement, no mention of choosing this over list_leads or get_lead, and no prerequisites.

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

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

Annotations already declare readOnlyHint, idempotentHint, non-destructive and closed-world, so the safety profile is fully covered and the description correctly avoids restating it. It adds the tenancy scoping context, but says nothing about ordering, whether 'recent' means a bounded time window, or pagination behavior beyond what the schema's limit/offset descriptions already state.

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

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

A single front-loaded sentence with zero filler, appropriate for a simple read tool. It is concise but bordering on under-specified rather than over-verbose.

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

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

An output schema exists and the input schema is fully self-documenting, so the description needn't explain returns. However, the key ambiguity unique to this tool — what 'recent' covers and the default sort direction — is left unresolved in both the description and the schema.

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

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

Schema description coverage is 100% — every parameter (limit, offset, status, agent_id) is documented inline with defaults and ranges. The description adds no filter semantics, such as which status values are valid or how agent_id interacts with the business scope, so nothing exceeds the baseline.

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

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

States a specific verb and resource ('List recent calls') plus a scope qualifier ('for the authenticated business'), so the agent knows it returns a tenant-scoped collection. It does not distinguish itself from siblings like list_leads or list_voicemails beyond the resource noun, and 'recent' is never 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?

No guidance on when to use this versus alternatives such as check_call_status, get_transcript, or get_call_recording, and no mention of what to do when the needed call is outside the 'recent' window. The agent must infer everything about selection.

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

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint=false, so the safety profile is covered. The description still earns credit for adding value beyond them: it discloses that results are scoped to the authenticated business and that each item carries transcripts and recording URLs, which tells an agent it may not need separate transcript/recording calls. It stops short of defining the 'recent' window or ordering.

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

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

A single sentence with no filler, front-loading the verb, resource and scope before the returned payload. Every clause 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?

An output schema exists, so return values need no prose explanation, and annotations cover safety. Combined with the description's coverage of scope and payload, an agent has enough to call it correctly; only the definition of 'recent' and result ordering remain unspecified.

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

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

Schema coverage is 100% and both parameters (limit, offset) are fully documented with defaults, bounds and pagination semantics in the schema. The description adds nothing about them, which is acceptable given the schema does the work, so the baseline of 3 applies.

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

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

The description states a specific verb and resource ('List recent voicemails') and adds scope ('for the authenticated business') plus the payload ('transcripts and recording URLs'). It does not explicitly distinguish itself from siblings like list_recent_calls or get_transcript, so an agent must infer the boundary, but the resource itself is unambiguous.

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

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

There is no statement of when to use this tool versus get_transcript, get_call_recording, or list_recent_calls, nor any prerequisites. The word 'recent' implies a time window but never defines it, leaving selection logic entirely to inference.

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

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

Annotations already declare readOnlyHint, idempotentHint, non-destructive and closed-world, so the safety profile is covered. The description adds one genuinely useful behavioral detail — 'credential-free' — plus the REST endpoint it mirrors, but says nothing about result size, caching, or stability of the catalog beyond the word 'curated'.

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

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

A single sentence with the resource and scope front-loaded and zero filler. Every clause (curated, credential-free, field list, endpoint mirror) carries 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?

With an output schema present and full parameter coverage, the description does not need to explain return values or filters. It is complete for a simple read-only catalog listing; only a word on ordering or result size would improve it.

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

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

Schema description coverage is 100% with three optional filters, each documented with examples (e.g. '11labs or azure'). The description only names gender and language as output fields rather than explaining filter behavior, so it adds no meaning beyond the schema — baseline 3 applies.

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

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

States a specific verb and resource ('List the curated, credential-free voice catalog') and enumerates the returned fields, so the agent knows exactly what comes back. It does not differentiate from the nearest sibling (list_agents), which is the only thing keeping it from a 5.

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?

Usage is only implied by the clause 'used to configure agent voices', which tells the agent the downstream context but not when to call this versus alternatives or whether any prerequisites exist. No explicit when/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?

Annotations already establish the safe read-only, idempotent profile, and the description adds useful behavioral context: this is a static catalog with no per-business state, and its examples are directly reusable with create_campaign. It does not discuss pagination or rate limits, but those are minor for a static catalog and an output schema is present.

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

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

The description is three sentences, front-loaded with what is listed and followed by useful details about the example configs and static nature. 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?

With zero parameters and an output schema present, the description gives an agent everything needed: what the tool returns, that it is static, and that the example configs are compatible with create_campaign. No critical context is missing.

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

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

There are no parameters, so parameter semantics are not a meaningful source of ambiguity. The baseline score of 4 applies.

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

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

The description uses a specific verb and resource: it lists cadence/campaign workflow templates and names the template categories and returned details. The phrase 'Static catalog — no per-business state' distinguishes it from per-business sibling tools such as list_campaigns.

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 clearly implies usage by noting the cadence_config examples match what create_campaign accepts, giving the agent a concrete reason to call this before creating a campaign. It stops short of explicitly naming when not to use it or contrasting it directly with alternatives like list_config_versions.

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?

Goes well beyond the annotations by disclosing side effects: it replaces saved derived state, may record level-change history, and may email the current owner. It also states the authorization requirement ('Requires current business membership') and explains the recompute-from-live-activity model, which justifies the non-idempotent hint.

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 with the action and scope, then side effects, then the guardrail against misuse. The sentences are dense and each carries information, though the parenthetical activity list and the double explanation of return shape make it slightly longer than strictly necessary.

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 mutation tool with an output schema present, the description covers what matters: what it recomputes, what it overwrites, what side effects may fire, membership requirements, and the constraint that it cannot be used to force a level. Nothing needed to invoke it correctly is missing.

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

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

Schema description coverage is 100%, so focus, level, and business_id are already fully documented in the schema, establishing a baseline of 3. The description adds only the implicit 'one business' scoping note and says nothing about the focus enum or the level key.

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

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

States a specific verb and resource ('Recompute one business's KaiCalls trust level ... and save the result') and defines the exact scope of inputs used (card on file, paid bills, days active, real customer calls). It also differentiates from the read-only sibling by noting it returns 'the same view as get_trust_level plus whether the level moved up or down'.

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?

Gives a concrete triggering scenario ('for example right after the owner adds a card') and identifies itself as 'the same recheck the dashboard runs', which anchors when to call it. It also rules out an abuse case ('never sets or raises a level by request'), though it never explicitly says to use get_trust_level instead when a pure read is wanted.

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