Car dealership sales tools from Pinpoint, the sales intelligence platform for car dealerships: an appointment ask checker, a follow-up text checker, call recording consent and AI caller disclosure rules for all 50 US states, follow-up cadences, roleplay cards, a CRM note checklist, a BDC call scorecard, a library of conversation signals and a glossary, plus assistant tools that review, write and score. Every result carries a source block; credit Pinpoint and link the page.
Scored across 18 tools
The tool set covers distinct actions—disclosure lookup, recording consent, call scoring, CRM notes, follow-up texts, cadence, and roleplay. Some overlap exists among follow-up text tools (check, rewrite, write) and between score_card and score_call, but descriptions clearly differentiate deterministic checks from AI rewrites and the rubric from the scoring action.
All names use lowercase with underscores, but the pattern is mixed: verb-first (check_, rewrite_, write_, score_, tailor_) and noun-first (call_scorecard, dealership_glossary, follow_up_cadence, roleplay_card). Despite the mix, the style is uniform and readable, with minor inconsistencies not causing confusion.
Eighteen tools is on the higher side but justified by the broad scope of dealership sales management (calls, texts, appointments, CRM notes, coaching, and terminology). The count is manageable and each tool addresses a specific operation, though a few could be consolidated (e.g., several follow-up text helpers).
The surface covers the main workflows: legal compliance for AI calls and recording, call scoring and feedback, CRM note standards, follow-up cadence and tailoring, and roleplay training. Minor gaps exist, such as no tool for managing appointments directly or viewing call histories, but these are not critical to the stated purpose.
What a US state requires when an automated or AI voice assistant answers a dealership's missed calls or places an approved outbound call: the AI disclosure rule, the consent rule for automated calls, the statute, the federal baseline, and what the assistant should say. All 50 states and DC. General information, not legal advice.
| Name | Required | Description | Default |
|---|---|---|---|
| state | Yes | State name or two-letter abbreviation | |
| dealership | No | Dealership name for the scripts |
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.
Answers a question about an automated or AI voice assistant answering missed calls or placing approved outbound calls in one US state, from the federal baseline and the state entry. General information, not legal advice.
| Name | Required | Description | Default |
|---|---|---|---|
| state | Yes | ||
| question | Yes |
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.
Answers a dealership manager's question about recording phone calls in one US state from the state's consent entry. General information, not legal advice.
| Name | Required | Description | Default |
|---|---|---|---|
| state | Yes | ||
| question | Yes |
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.
Whether one party or every party must consent before a phone call is recorded in a US state, the statute, a note for dealerships, and the greeting, outbound and text notices a dealership should use. All 50 states and DC. General information, not legal advice.
| Name | Required | Description | Default |
|---|---|---|---|
| rep | No | Rep first name for the outbound notice | |
| state | Yes | State name or two-letter abbreviation, for example "FL" or "Florida" | |
| dealership | No | Dealership name for the notices |
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.
The eighteen-item pass-or-fail scorecard for a dealership sales call, in five groups (open, discovery, the ask, control, close and record), with the scoring rules and the four-minute review method.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
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.
Deterministic check of one dealership appointment ask using six fixed text-pattern rules: day, clock time, holding the time, confirmation question, vehicle mention or readiness phrase, and follow-up. Returns a structured score, per-part flags and fixes, and a fixed template example that reuses a detected day and time or supplies sample values when absent. Runs without an AI model. Use this for repeatable rule-based scoring; use review_appointment_ask for contextual AI feedback and a tailored rewrite.
| Name | Required | Description | Default |
|---|---|---|---|
| text | Yes | What the salesperson said when offering the appointment |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the annotations (readOnlyHint true, openWorldHint false), the description discloses deterministic behavior, fixed text-pattern rules, outputs (structured score, flags, fixes, template), and that it runs without an AI model. This adds significant behavioral context not captured by annotations alone.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded: the first sentence states the core purpose and the six rules, followed by output details and usage guidance. No redundant sentences; every clause adds useful 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?
For a simple tool with one required parameter and no output schema, the description completely covers what it does, how it behaves, what it returns, and when to use it vs. alternatives. Nothing essential is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% for the single parameter 'text', which is described as 'What the salesperson said when offering the appointment'. The tool description adds value by explaining how the text is evaluated (six fixed rules) and that detected day/time are reused in the template, giving the agent better context on what content to provide, though it doesn't introduce new parameter constraints.
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 tool as a deterministic check of an appointment ask using six specific text-pattern rules, and it distinguishes itself from the sibling review_appointment_ask. It states the verb (check), the resource (appointment ask), and the exact evaluation criteria, leaving no ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly instructs when to use this tool versus the alternative: 'Use this for repeatable rule-based scoring; use review_appointment_ask for contextual AI feedback and a tailored rewrite.' Also notes that it runs without an AI model, giving clear context for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Checks a dealership follow-up text message against eight practices: identifies the sender and store, refers to what the customer asked about, one question at most, a specific next step, no price or payment or trade value, an easy way out, two segments or fewer, no all-caps urgency. Returns what passed, what failed and why.
| Name | Required | Description | Default |
|---|---|---|---|
| text | Yes | The text message as it would be sent |
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.
The 40 moments in a dealership sale worth acting on, in six groups (buying signals, appointment handling, follow-up gaps, coaching moments, record gaps, agent handoffs). Without a signal, returns the list; with a signal slug, returns what it sounds like, why it matters, what to do next, how to coach it and how to practice it.
| Name | Required | Description | Default |
|---|---|---|---|
| signal | No | A signal slug from the list |
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.
What a complete CRM note carries after a dealership sales call or text thread, in five sections, with an example of a strong note and the lead statuses that mislead managers.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
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.
Plain definitions of 100 terms dealership sales teams use, from appointment set rate and BDC to approved action and human handoff. Returns the matching term, or the closest matches.
| Name | Required | Description | Default |
|---|---|---|---|
| term | Yes | The term or a word in it |
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.
The follow-up sequence for a dealership sales situation (new internet lead, missed inbound call, unconfirmed appointment, no-show, quote without an appointment, trade question without an appointment, text thread gone quiet, sold first week): the starting event and each step's timing, channel, purpose, message with the names filled in, and the reply that stops it. Use startLabel to anchor the sequence; a step's whenLabel takes precedence over its retained legacy day value.
| Name | Required | Description | Default |
|---|---|---|---|
| rep | No | The salesperson's first name | |
| vehicle | No | The vehicle of interest | |
| situation | Yes | The situation slug | |
| dealership | No | The dealership name | |
| day_and_time | No | The day and time on the table, for example "Saturday at 12:30" | |
| customer_first_name | No | The customer's first name |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=false, so the safety profile is covered. The description adds behavioral context: output is a step sequence, names are filled in, a reply stops the sequence, and whenLabel overrides retained legacy day values. The label references are not defined in the input schema, but they still provide useful output-behavior transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the core purpose and returns a dense but relevant list of output components. The technical note about startLabel and whenLabel is compact but somewhat jargon-heavy; the long parenthetical list of situations could be cleaner, but it earns its place by enumerating supported inputs.
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 does a good job of clarifying what the caller will receive: the starting event, step timing/channel/purpose/message, and the stopping reply. Some output fields like startLabel and whenLabel are referenced without full definition, leaving minor ambiguity, but overall it is sufficient for a read-only retrieval 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 parameter semantics baseline is met by the schema. The description adds no additional parameter-level clarification beyond implying that names are filled into the generated messages, which is already evident from the schema fields.
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 names the resource ('follow-up sequence') and its scope ('dealership sales situation'), then enumerates the exact eight supported situations. It also details the returned content: starting event, per-step timing, channel, purpose, personalized message, and the stopping reply. This clearly distinguishes it from 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 when to use the tool by listing the supported situations moderating it, but it provides no explicit guidance on when not to use it or how it compares to sibling tools such as tailor_follow_up_cadence. The usage context is present, but exclusions and alternatives are left to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Uses the configured AI assistant to review one dealership appointment ask in context. Returns prose with a verdict, present and missing parts, a tailored rewrite in the rep's voice, and one coaching line. Choose this for phrasing and coaching; use check_appointment_ask for deterministic six-part scoring and a fixed template example. Available only when an assistant provider is configured.
| Name | Required | Description | Default |
|---|---|---|---|
| ask | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already indicate read-only, non-destructive behavior. The description adds meaningful behavioral context by disclosing that it depends on a configured AI assistantwhere results are prose-like and includes a verdict, parts analysis, rewrite, and coaching line. It does not fully specify how the 'context' is sourced or how variable the AI output may be, but the openWorldHint partly covers that.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and front-loaded: first sentence states what the tool does and returns, second sentence gives routing guidance, third states the dependency. Every sentence adds 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?
For a tool with a single string parameter and no output schema, the description provides strong context: output contents, sibling distinction, and availability condition. The only slight gap is that 'in context' is not fully explained—what specific context the AI assistant uses is left implicit—but this does not prevent 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?
The input schema only defines `ask` as a required string with no description, and schema coverage is 0%. The description compensates implicitly by referring to 'one dealership appointment ask' and 'a tailored rewrite in the rep's voice,' making it clear that `ask` is the draft text to be reviewed. However, it does not explicitly define expected length, format, or examples.
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: 'review one dealership appointment ask in context' using the configured AI assistant. It also differentiates itself from the sibling check_appointment_ask by contrasting prose coaching output with deterministic scoring, so an agent can identify the intended purpose immediately.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says when to choose it ('Choose this for phrasing and coaching') and when not to, naming check_appointment_ask as the alternative for deterministic six-part scoring. It also includes a clear preconditions warning: 'Available only when an assistant provider is configured.'
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Checks a follow-up text against eight practices and rewrites it to pass them.
| Name | Required | Description | Default |
|---|---|---|---|
| text | Yes |
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.
A practice card for a dealership sales roleplay: a customer type (twelve, from the price shopper to the callback who went quiet) and an objection (eight, from "I need to think about it" to "just email me the numbers"): the customer's opening line, what they want and fear, their tells, the objection as the customer says it, the salesperson's goal, what a strong answer sounds like, and the feedback checklist.
| Name | Required | Description | Default |
|---|---|---|---|
| objection | Yes | ||
| customer_type | Yes |
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.
Scores a dealership sales call transcript, notes or summary against the eighteen-item BDC scorecard: pass, fail or not observable per item with evidence, and a coaching note.
| Name | Required | Description | Default |
|---|---|---|---|
| transcript | Yes | Transcript, notes or a summary of one call, up to 6,000 characters |
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.
Scores a CRM note written after a sales call or text thread against what a complete note carries, and rewrites it complete with brackets for missing facts.
| Name | Required | Description | Default |
|---|---|---|---|
| note | Yes |
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.
Rewrites every step of a situation's follow-up cadence for the customer you describe, keeping the days, times and channels.
| Name | Required | Description | Default |
|---|---|---|---|
| rep | No | ||
| vehicle | No | ||
| customer | Yes | Who the customer is and what they care about | |
| situation | Yes | ||
| dealership | No | ||
| day_and_time | No | ||
| customer_first_name | No |
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.
Writes two dealership follow-up texts for a situation you describe: under 300 characters, names the rep and store, one question, a way out, no price or payment or trade value.
| Name | Required | Description | Default |
|---|---|---|---|
| rep | No | ||
| vehicle | No | ||
| situation | Yes | What happened with the customer | |
| dealership | No | ||
| day_and_time | No | ||
| customer_first_name | No |
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.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
ai_caller_disclosureanswer_ai_caller_questionanswer_recording_questioncall_recording_consentcall_scorecardcheck_appointment_askcheck_follow_up_textconversation_signalscrm_note_checklistdealership_glossaryfollow_up_cadencereview_appointment_askrewrite_follow_up_textroleplay_cardscore_callscore_crm_notetailor_follow_up_cadencewrite_follow_up_texts
Add one secure layer between your agents and this server.