Pinpoint dealership sales tools

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

Annotations already declare readOnlyHint=true, indicating no side effects. The description adds that it covers all 50 states and DC, is general information, and not legal advice—useful context for an agent. However, it does not disclose behavior for invalid states or output format details, which are minor given the read-only nature.

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

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

The description is a single, well-structured sentence that front-loads the core purpose ('What a US state requires') and uses a colon to enumerate the specific outputs. It is concise but packs necessary information 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?

With no output schema, the description lists what the agent can expect (rule, consent, statute, federal baseline, script guidance), which is sufficient for a simple lookup tool. It does not mention error handling for invalid states, but that is a minor gap given the read-only nature and clear parameter validation implied by 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 descriptions already cover both parameters ('State name or two-letter abbreviation' and 'Dealership name for the scripts'). The description adds context that the dealership name is used for scripts ('what the assistant should say'), but it does not clarify the optionality of the dealership parameter or provide additional format details 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: it provides state-specific requirements for AI caller disclosure, including the rule, consent rule, statute, federal baseline, and script guidance. This is specific and distinct from sibling tools that handle call scoring, follow-ups, or other topics.

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 a user needs state-specific disclosure rules, but it does not explicitly state when to use this tool versus alternatives or when not to use it. The caveat 'General information, not legal advice' is a disclaimer rather than usage 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?

Annotations already provide readOnlyHint and openWorldHint, so the description only needs extra context. It adds that the result is general information rather than legal advice, is scoped to one US state, and draws on the federal baseline and state entry. This is useful behavioral context and does not contradict the annotations.

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

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

The description is two sentences, front-loaded with the main action and scope. The phrase 'from the federal baseline and the state entry' is somewhat cryptic but compact, and the disclaimer 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 two-string Q&A tool with read-only/open-world annotations, the description covers the domain, geographic scope, and non-legal nature of the answer. It is missing explicit sibling routing and output-shape hints, but those are more relevant to other dimensions.

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 must compensate for the two parameters. It clarifies that state refers to a US state and question concerns AI voice assistants, adding meaning beyond the bare schema. Still, it leaves the accepted state format/values and expected question phrasing unspecified.

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 action ('Answers a question') and a precise domain: an automated/AI voice assistant handling missed calls or approved outbound calls in one US state. This clearly differentiates it from siblings like answer_recording_question and ai_caller_disclosure by topic and scope.

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

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

The description implies the tool is for state-specific informational questions about AI-caller practices, and 'not legal advice' sets a boundary. However, it never names alternatives or states when not to use this tool, so sibling selection is left 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=true and openWorldHint=true, so the safety profile is covered. The description adds behavioral value by stating that output is 'General information, not legal advice' and that answers are derived 'from the state's consent entry', which sets expectations about scope and authority. This does not contradict the annotations.

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

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

The description is two sentences with no filler. The core function is front-loaded in the first sentence, and the essential caveat ('General information, not legal advice') is placed second. Every phrase earns its place, and the length is appropriate for the tool's low complexity.

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

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

For a low-complexity read-only Q&A tool with no output schema, the description covers the core purpose and a key caveat. However, it lacks details about what kinds of questions are answerable, whether state format matters, and how the answer might be structured. It is minimally viable but leaves an agent guessing on invocation details.

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 adds meaning by clarifying 'state' is a US state and 'question' pertains to recording phone calls. However, it does not specify expected formats (e.g., two-letter state code vs full name) or the level of detail needed in 'question'. The names are self-explanatory, but the description leaves some ambiguity.

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

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

The description clearly states a specific verb ('Answers') and resource: a dealership manager's question about recording phone calls in one US state, sourced from the state's consent entry. It distinguishes itself from legal advice, and implicitly from sibling tools like answer_ai_caller_question by narrowing scope to call-recording questions. It could be slightly clearer about what 'consent entry' means, but the purpose 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?

No when-to-use or when-not-to-use guidance is provided. There is no mention of alternatives, exclusions, or conditions that would help an agent choose this tool over siblings like call_recording_consent or answer_ai_caller_question. The 'General information, not legal advice' caveat is a disclaimer, not usage 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?

Annotations already declare readOnlyHint=true, so the description doesn't need to state it's read-only. It adds value by clarifying the scope ('All 50 states and DC') and the non-legal nature ('General information, not legal advice'). This goes beyond the annotations without contradicting them.

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, compact sentence that front-loads the core purpose (consent requirement) and then lists secondary contents (statute, note, notices). It wastes no words and 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?

For a simple read-only reference tool with 3 parameters and no output schema, the description covers key aspects: what data is returned (consent rule, statute, notice templates), the scope (all states+DC), and a cautionary note (not legal advice). It does not detail the output format, but given the low complexity, this is 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 description coverage is 100%: all parameters (state, rep, dealership) already have descriptions in the schema. The tool description does not add further meaning to the parameters beyond what the schema provides, so a baseline of 3 is appropriate.

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

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

The description clearly states the tool provides consent rules (one-party vs. all-party), the relevant statute, a dealership-specific note, and sample notices for a given US state. This is a specific verb+resource and distinguishes it from siblings like answer_recording_question, which answers questions, or ai_caller_disclosure, which likely provides disclosure scripts.

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 state-specific consent laws and notices) but does not explicitly state when to use this tool versus alternatives like answer_recording_question. It provides context like 'for dealerships' but no exclusions or explicit routing 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?

Annotations already declare readOnlyHint=true and openWorldHint=false, indicating a safe, read-only reference. The description adds value by enumerating the five groups and mentioning the scoring rules and four-minute review method, going beyond the bare annotations to clarify the tool's content and scope.

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 that leads with the core identity ('The eighteen-item pass-or-fail scorecard') and then efficiently adds specifics (groups, scoring rules, review method). 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?

For a zero-parameter read-only reference tool with no output schema, the description adequately conveys the tool's content: eighteen items, five groups, scoring rules, and review method. While it does not enumerate the actual rules or output format, it gives a clear sense of what the agent will receive, which is sufficient for a static reference.

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 zero parameters, and the schema is empty with 100% coverage. The description correctly adds no parameter information since none exist, meeting the baseline expectation for a parameterless tool. No further elaboration is needed.

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 explicitly identifies the tool as the eighteen-item pass-or-fail scorecard for dealership sales calls, structured in five groups, and mentions scoring rules and a review method. It clearly distinguishes itself from siblings like score_call (which likely applies the scorecard) by positioning this as the reference definition.

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

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

The description does not provide explicit when-to-use guidance or name alternatives. Its nature as a reference tool implies usage when an agent needs the scoring criteria, but it does not explicitly say to use this instead of score_call or roleplay_card, leaving some inference required.

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 readOnlyHint=true and openWorldHint=false, so safety is disclosed. The description adds meaningful behavioral context by stating the tool 'returns a stronger version,' revealing that the output is an improved/reformulated text rather than just an evaluation. It also lists the six parts, giving the agent a clear sense of what the tool inspects. This goes beyond the annotations without contradicting them.

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 sentence that front-loads the main action and then enumerates the six parts. It is clear and efficient, though the parenthetical list is a bit dense. No unnecessary fluff, and the key behavior is stated upfront.

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 no output schema, so the description must explain the return value. It says 'returns a stronger version,' but this is vague—does it return just the rewritten text, or also a score? For a simple one-parameter tool with read-only annotations, the description covers input and high-level behavior, but lacks specifics about the output format. An agent might need more detail to use the result correctly.

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

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

Schema coverage is 100% and the parameter 'text' already has a clear description. The tool description essentially repeats the schema's parameter description ('what a dealership salesperson said when offering an appointment') and adds the six-part detail, which helps the agent understand what content is relevant. This is marginal added value, so the baseline of 3 is appropriate.

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

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

The description clearly states the verb 'Checks' and the resource: what a dealership salesperson said when offering an appointment. It also specifies the six parts of a visit, which clarifies scope. However, it does not differentiate from the sibling tool review_appointment_ask, which likely performs a similar check, so it misses the top score.

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 review_appointment_ask or any other sibling, nor does it give conditions for choosing this over rewrite_follow_up_text or similar tools. An agent must infer usage from the name and description alone, which is insufficient given the large sibling 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?

Annotations already declare readOnlyHint=true, indicating this is a read-only operation. The description adds value by detailing the eight specific practices checked and the nature of the result (passed/failed/why). It does not introduce any side effects or contradictions. It goes beyond the annotations by specifying the check criteria and return 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?

The description is a single sentence that front-loads the purpose ('Checks a dealership follow-up text message') and then lists the eight practices concisely. While the list is long, each item is necessary and there is no filler. The structure is efficient and informative.

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 only one input parameter and no output schema, the description provides enough context: it enumerates the check criteria and indicates the result format ('what passed, what failed and why'). This is sufficient for an agent to understand what the tool does and what to expect, even though it doesn't specify exact output fields. Given the tool's simplicity, this is adequate.

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

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

The only parameter 'text' is fully described in the input schema ('The text message as it would be sent'). The description does not add any additional semantic detail about the parameter beyond what the schema already provides. Since schema description coverage is 100%, the baseline of 3 applies; no extra credit is warranted.

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

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

The description clearly states a specific verb (checks), a specific resource (dealership follow-up text message), and enumerates the eight practices it evaluates. It also indicates the output (what passed, what failed and why). This distinguishes it from sibling tools like rewrite_follow_up_text or write_follow_up_texts, which generate or modify text rather than evaluate 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 description makes the use case clear: evaluating a follow-up text against eight practices. It implies when to use it (when you need to check a text) but does not explicitly mention when not to use it or name alternatives. Since the context is clear and there are no exclusions, it earns a 4 rather than a 5.

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

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

Annotations already mark readOnlyHint true and openWorldHint false. The description adds the key behavioral split between empty and populated parameters, explaining exactly what each call returns. No contradictions or hidden side effects are 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 packs a lot into one efficient sentence without fluff. It front-loads the domain and content groups, then explains conditional behavior. Slightly dense but every phrase 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 read-only lookup with one optional parameter and no output schema, the description fully covers both invocation modes and the shape of each response. An agent can call it correctly without further information.

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

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

The schema covers the 'signal' parameter 100% with 'A signal slug from the list', and the description reinforces that meaning while adding the crucial optionality behavior: omitting returns the full list, supplying a slug returns signal-specific details. This goes beyond schema-only 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 states a specific scope: 'The 40 moments in a dealership sale worth acting on', enumerated in six named groups. It clearly distinguishes this as a lookup/reference tool for conversation signals, not a generic glossary or action tool, and the conditional return behavior is explicit.

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

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

The description provides clear context on how to use the tool: without a signal slug it returns the list, with a slug it returns detailed guidance. It does not explicitly name sibling alternatives or exclusions, but the categorical groups effectively define when this tool is relevant.

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 include readOnlyHint=true, so the description's non-actionable nature aligns. It adds context about content (five sections, example, misleading statuses) but doesn't disclose whether it returns a static guide or dynamic analysis. With readOnlyHint, a baseline 3 is appropriate; description adds some value beyond 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 one sentence, front-loaded with the core purpose (what a complete CRM note carries), and efficiently lists content (five sections, example, statuses). It's concise without waste, though slightly dense.

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 zero-param, read-only reference tool, the description is fairly complete: it indicates the tool outputs guidance on CRM notes, including an example and warning about misleading statuses. It could mention whether it includes a checklist format, but enough is present for an agent to understand its role.

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 tool has zero parameters, so parameter semantics are not applicable. A baseline of 4 is given for zero-param tools, and the description clarifies what the tool provides despite having no inputs.

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 the tool defines what a complete CRM note carries, which is a clear purpose. It doesn't explicitly say it's a reference/guide, but the context signals (0 params, readOnlyHint) imply it, and it distinguishes from siblings like score_crm_note (which scores) and crm_glossary (which defines terms).

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 it's for understanding what a complete CRM note looks like, but doesn't explicitly say when to use it vs alternatives like score_crm_note or check_follow_up_text. It mentions lead statuses that mislead managers, hinting at a cautionary use, but lacks explicit routing.

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

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

Annotations already declare readOnlyHint=true, so the agent knows this is a safe read operation. The description adds that it returns the matching term or closest matches, which is useful behavioral context. It doesn't disclose edge cases like no-match behavior or fuzzy matching details, but the annotations cover the safety profile.

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 that front-loads the core purpose and includes the return behavior. Every word earns its place, and it's appropriately sized for a simple glossary lookup 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?

For a simple read-only glossary tool with one parameter and no output schema, the description is nearly complete. It states the scope (100 terms), the domain (dealership sales), and the return behavior (matching term or closest matches). The only minor gap is not specifying what happens when no match is found, but this is a minor omission for such a simple 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 the single parameter 'term' as 'The term or a word in it'. The description adds that it returns the matching term or closest matches, which slightly clarifies behavior but doesn't add significant meaning beyond the schema. Baseline 3 is appropriate.

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

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

The description clearly states the tool's purpose: providing plain definitions of dealership sales terms. It names the resource (glossary of 100 terms) and the action (returns matching term or closest matches). It doesn't explicitly differentiate from siblings, but the glossary function is distinct enough from the other tools listed.

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: an agent would use this when a user asks for a dealership sales term definition. It doesn't explicitly state when not to use it or name alternatives, but the context signals and sibling list make the use case fairly clear. No explicit exclusions or alternative routing are 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 declare readOnlyHint=true, so the agent knows this is a safe read operation. The description adds value by detailing what the returned sequence contains, including personalized names and a stopping reply, but it does not go into deeper behavioral details such as whether the output is generated, templated, or formatted in a particular way.

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, dense sentence that packs the situation list and output components into one readable string. It is efficient but slightly run-on; the parenthetical list and trailing colon sequence make it harder to parse than a structured multi-sentence description would be.

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 read-only tool with a rich output description, the definition covers what the tool returns and which situations it applies to. The lack of an output schema is compensated by the explicit list of step attributes, though it does not explain how optional parameters affect personalization.

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 six parameters, including the situation enum. The description references name-filled messages and day/time components, which loosely maps to rep, customer_first_name, and day_and_time parameters, but it does not add explicit parameter-level meaning beyond 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?

The description clearly identifies the resource as the follow-up sequence for a dealership sales situation and specifies the output components: day, time, channel, purpose, message, and stopping reply. It is specific but does not explicitly differentiate itself from the sibling tools like write_follow_up_texts or tailor_follow_up_cadence.

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 the tool is used for the enumerated sales situations but provides no guidance about when to choose it over sibling tools such as write_follow_up_texts, rewrite_follow_up_text, or check_follow_up_text. There are no exclusions, alternatives, or contextual triggers beyond the listed situations.

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, so the safety profile is covered. The description adds useful behavioral context by enumerating the tool's expected outputs: verdict, present and missing parts, rewrite in the rep's voice, and one coaching line. It does not explain what a 'verdict' is, but it goes beyond the annotations meaningfully.

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 tight sentence with a colon-separated list of outputs. It is front-loaded, scannable, and contains no filler or repetition.

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

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

For a single-string input with no output schema, the description covers both the input and the output dimensions. However, it leaves the meaning of 'verdict' vague and provides no context about when to invoke this tool relative to similar siblings, so an agent still has 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?

Schema description coverage is 0%, so the description must carry parameter meaning. It clarifies that the 'ask' input is the salesperson's statement when offering an appointment, which adds meaning beyond the bare string type. However, it does not specify expected format, length, or whether verbatim text is required.

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

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

The description uses the specific verb 'Reviews' and names the resource ('what a salesperson said when offering an appointment'), then lists concrete outputs: verdict, present/missing parts, rewrite, and coaching line. It is clear, but it does not explicitly distinguish this tool from the sibling check_appointment_ask, which likely overlaps.

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 use review_appointment_ask versus check_appointment_ask or rewrite_follow_up_text. The description only states what the tool does, with no conditions, exclusions, or alternatives to help an agent select 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?

Annotations already declare readOnlyHint=true and openWorldHint=true, indicating a safe, read-only transformation. The description adds that the tool checks and rewrites the text, which is consistent. It does not disclose details like whether the original meaning is preserved or how output is returned, but annotations cover the safety profile.

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 sentence with zero waste. The core action is front-loaded, and every word adds value. It conveys what the tool does in a highly efficient manner.

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 tool with one string parameter and annotations covering safety, the description is adequate. It does not describe the output format or what the eight practices are, but those may be covered by sibling tools (e.g., check_follow_up_text). With no output schema, an agent might still wonder what exactly is returned, so completeness is moderate.

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% with a single parameter named 'text'. The description clarifies that the text is a 'follow-up text' and that it will be checked against practices, adding meaning beyond the raw schema. However, it omits any constraints or format expectations, which would be more helpful given zero 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 specifies a concrete action (rewrites a follow-up text) and a distinguishing detail (against eight practices). It differentiates from siblings like check_follow_up_text (which only checks) and write_follow_up_texts (which writes from scratch) implicitly through the verb 'rewrites', but it does not explicitly name alternatives.

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: the tool is for rewriting an existing follow-up text so it passes eight practices, which suggests using it when you already have a draft. However, there is no explicit statement about when to use this versus check_follow_up_text or write_follow_up_texts, nor any mention of 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?

Annotations declare readOnlyHint=true and openWorldHint=false, and the description does not contradict them. It adds behavioral detail by specifying exactly what the card contains, including the customer's opening line, wants and fears, tells, objection phrasing, salesperson goal, strong answer, and feedback checklist, which helps the agent understand the expected return content.

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 dense run-on sentence that front-loads the core purpose but packs many details into a long colon-chain. It contains no filler, yet it would be more readable and structured as a brief purpose statement followed by a bullet-style list of output fields.

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

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

With no output schema, the description carries the burden of explaining what the tool returns, and it does so in detail by enumerating all card components. The closed enum sets and read-only annotation complete the picture well enough for an agent to invoke the tool, though instructions on how to use the card in a roleplay session are absent.

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 partially compensates by giving the ranges of customer types and objections, e.g. 'from the price shopper to the callback who went quiet.' However, it does not enumerate or define each enum value, so the agent still relies on the self-descriptive enum identifiers for full semantics.

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

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

The description clearly identifies this as a practice card for a dealership sales roleplay, names the two inputs (customer type and objection), and enumerates the output contents (opening line, wants/fears, tells, objection wording, goal, strong answer, feedback checklist). This is specific and distinguishes it from sibling tools like call_scorecard or score_call.

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 purpose implies use in sales roleplay practice, but there is no explicit when-to-use or when-not-to-use guidance. It does not name alternatives or contrast with sibling tools such as rewrite_follow_up_text or score_call, leaving the selection context to be inferred.

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 indicate readOnlyHint=true and openWorldHint=true, and the description adds meaningful behavioral detail by specifying the output format: pass/fail/not observable per item, including evidence and a coaching note. This goes beyond the annotations by clarifying what the tool returns, though it does not discuss auth, rate limits, 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?

The description is a single, focused sentence that front-loads the core action and immediately specifies the scoring criteria and output. There is no filler or redundancy, but it is slightly long and could be split into two sentences for readability without loss of meaning.

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

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

With one simple parameter and no output schema, the description covers the input and the main output categories, but it does not specify the exact return structure (e.g., JSON shape, per-item format, whether coaching note is a single string or per-item). Additional detail about the response format would make it more complete for an agent.

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

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

Schema description coverage is 100% and the only parameter 'transcript' is clearly described in the schema as 'Transcript, notes or a summary of one call, up to 6,000 characters.' The tool description repeats this concept but does not add new meaning beyond what the schema already provides, 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 ('Scores'), a clear resource ('dealership sales call transcript, notes or summary'), and a specific scoring framework ('eighteen-item BDC scorecard'). It also outlines the output per item (pass/fail/not observable with evidence and coaching note), which fully distinguishes it from siblings like score_crm_note.

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 describing what the tool does, but it does not explicitly state when to use it versus alternatives such as score_crm_note or call_scorecard. There is no when-not guidance or explicit routing to sibling tools, leaving the agent to infer the appropriate 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?

The description discloses the dual behavior of scoring and rewriting, which adds context beyond the readOnlyHint annotation. However, it does not clarify whether the original note is modified or a new version is returned, and it doesn't explain how the score is delivered. Given the annotations already indicate read-only behavior, the description should clarify the output format but remains ambiguous on this point.

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 that leads with the primary action ('Scores') and efficiently conveys the full behavior. There is no fluff or redundancy, making it easy for an agent to parse quickly.

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 no output schema, so the description must explain what the tool returns. The description says it 'scores' and 'rewrites', but it doesn't explicitly state whether the return value is the rewritten note, a score, or both. This ambiguity leaves the agent uncertain about the expected output, making the definition incomplete for correct invocation.

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 must compensate. It provides context that the 'note' is a CRM note written after a sales call or text thread, which adds meaning beyond the schema's bare 'string' type. However, it doesn't specify the expected structure, length, or what constitutes a 'complete note', leaving some semantic 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 the tool's action: it scores a CRM note and rewrites it with brackets for missing facts. The verb+resource is specific, and the purpose is unambiguous. However, it does not explicitly differentiate from sibling tools like crm_note_checklist, which might have overlapping functionality, so it misses the opportunity to distinguish itself.

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 the context 'after a sales call or text thread' but provides no explicit guidance on when to use this tool versus alternatives. There is no mention of exclusions, prerequisites, or when another tool would be more appropriate. The agent is left to infer usage from the description alone.

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 declare readOnlyHint=true and openWorldHint=true, which already communicate that the tool is safe and can handle unknown inputs. The description adds the constraint that it preserves days, times, and channels, which is useful behavioral context. However, it does not elaborate on side effects, permissions, or how open-world handling works, so it adds only modest value beyond the annotations.

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

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

The description is a single, focused sentence that front-loads the core action ('Rewrites every step of a situation's follow-up cadence') and includes the key constraint (keeping days, times, and channels). There is no redundant or filler content; every word contributes.

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 7 parameters and no output schema, the description should explain what the output looks like and how each parameter contributes. It does not describe the return format or the purpose of most parameters. The annotations cover safety, but the description lacks essential operational details, making it incomplete for an agent to call correctly without further inference.

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 only 14% (only the 'customer' parameter has a description). The description mentions 'the customer you describe' but does not explain the roles of rep, vehicle, situation, dealership, day_and_time, or customer_first_name. Since the schema is sparse, the description should compensate by clarifying these parameters, but it does not. It adds meaning to the customer parameter but leaves the rest ambiguous.

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 action: rewrites every step of a situation's follow-up cadence for a specific customer, while preserving days, times, and channels. This clearly distinguishes it from sibling tools like follow_up_cadence (which likely creates a generic cadence) and rewrite_follow_up_text (which rewrites text content).

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 any exclusions or reference sibling tools such as follow_up_cadence or rewrite_follow_up_text, leaving the agent to infer the appropriate context. No when-to-use or when-not-to-use criteria 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 readOnlyHint=true and openWorldHint=true, so the agent knows this tool has no side effects and can accept arbitrary situations. The description adds behavioral detail about the output content (length, required elements, prohibited elements) which is useful. However, it does not describe the return format (e.g., whether it returns a list of two strings or something else) or any error handling. Given the annotations cover safety, the description adds moderate value, so a 3 is appropriate.

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, dense sentence that front-loads the core action and constraints. It is concise with no wasted words, making it easy for an agent to parse quickly. It efficiently covers the tool's purpose and key output requirements.

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 generation tool with one required parameter and no output schema, the description covers the essential usage: it states the tool writes two texts, specifies content constraints, and implies that the situation is the primary input. The optional parameters (rep, vehicle, dealership, etc.) are self-explanatory and can be inferred from their names. The only minor gap is the explicit return structure, but it is reasonable to assume the tool returns the two texts. Overall, it is complete enough for correct invocation.

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 only 17% (only 'situation' is documented). The description helps clarify that 'rep' and 'dealership' are used in the generated text ('names the rep and store'), but it does not explain 'vehicle', 'day_and_time', or 'customer_first_name'. The parameter names are self-explanatory, but the description does not fully compensate for the low schema coverage. It adds some context but not enough to warrant a higher score.

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: it writes two dealership follow-up texts based on a described situation, with explicit content constraints (under 300 characters, names rep and store, one question, a way out, no price/payment/trade value). This distinguishes it from sibling tools like rewrite_follow_up_text (which edits existing texts) and check_follow_up_text (which evaluates texts). The verb 'writes' and the resource 'two dealership follow-up texts' are 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 implies when to use it – when you need new follow-up texts for a given situation. It does not explicitly mention alternatives or when not to use it, but the purpose is clear enough from the verb and the sibling tool names. There is no explicit exclusion, so it gets a 3 rather than a 4 or 5.

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