Groundbase

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

Annotations already declare readOnly=true, idempotent=true, destructive=false, so the safety profile is covered. The description adds the ordering guarantee ('newest first'), which is genuinely useful behavior not in the annotations, but says nothing about pagination, truncation, or the result window.

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

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

Two sentences, zero filler, with the ordering guarantee front-loaded before the optional scope qualifier. Every clause earns its place.

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

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

For a read-only list tool with no output schema, the description conveys the entity types returned and their ordering. The main omission is pagination/windowing behavior, but the schema's limit parameter and annotations cover most of the remaining risk.

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 25% (just limit). The description compensates for the three ID parameters by explaining they scope the feed to one contact, company, or deal, but leaves open whether they can be combined and says nothing about limit semantics beyond what the schema states.

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

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

States the resource (a unified recent-activity feed) and enumerates the event types it returns (texts, calls, emails, notes, deal stage changes, task completions). This implicitly distinguishes it from the per-type siblings (calls_list, sms_list, notes_list) as an aggregate view, though it never names them.

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

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

Usage is implied by 'Recent activity' plus the optional scoping sentence, so an agent can infer it answers 'what has happened lately for this record'. There is no explicit when-to-use versus calls_list/sms_list/notes_list, and no stated exclusions or prerequisites.

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

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

Annotations already declare readOnly/idempotent/non-destructive, so safety is covered. The description adds value by disclosing what the list returns (direction, duration, voicemail transcripts) and that single-call mode includes recording details, but it says nothing about pagination or how the default/vs max limit behaves.

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

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

A single well-formed sentence with the primary list purpose front-loaded and the alternate `id` mode appended. No wasted words.

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

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

With no output schema, the description partially compensates by naming returned fields, but leaves out pagination/limit behavior and the undescribed `contactId` parameter. Adequate for a simple read tool, but not fully complete.

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

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

Schema coverage is 75%, so the schema carries most parameter documentation; `limit`, `voicemailOnly`, and `id` are described there. The description only implicitly maps to `id` and doesn't mention `contactId` (undocumented in the schema) or limit semantics, so 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 states a specific verb+resource ('List call history') and enumerates the fields returned, then names the alternate single-fetch mode via `id`. It clearly separates list vs. single-call behavior, though it does not explicitly contrast itself with neighboring list tools like sms_list.

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

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

It gives explicit routing guidance: use the default list mode, or pass `id` to fetch a single call with recording details. There is no statement of when not to use it or of alternative tools, but the mode selection is unambiguous.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true and destructiveHint=false, so the safety profile is covered. The description adds useful behavioral context beyond that: what data is returned and the two distinct response shapes. It stops short of mentioning pagination behavior or default row counts, which rely on the schema.

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

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

Two dense sentences with zero filler. The primary mode and its metric list come first, and the alternate mode is appended as a compact clause.

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 describing returned data and does so by enumerating metrics and both response shapes. It is close to complete for a read-only analytics tool; only pagination/default-limit behavior is left to 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 coverage is 75%, with 'id' undocumented in both places. The description compensates meaningfully by clarifying that 'status' is a recipients-mode filter and that 'recipients' toggles between aggregate and row output — semantics the schema does not fully convey. The undescribed 'id' is self-evident given the context.

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

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

States a specific verb ('Stats') and resource ('one campaign') and then enumerates the exact metrics returned (recipients, sent, delivered, opens/clicks, bounces, unsubscribes, replies, failures). It also disambiguates the second mode ('With recipients: true, returns per-recipient rows instead'), making it clearly distinct from the campaigns_manage sibling.

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

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

The description explains the condition that switches to per-recipient output and when the status filter applies, which is implied usage guidance. However, it never states when to use this tool versus campaigns_manage or dashboard_summary, nor any prerequisites for the campaign id.

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?

Adds traits beyond the annotations: create only produces a draft, and send_now/schedule/resume reach real people so confirmation is required first. Annotations already declare destructiveHint/openWorldHint, so the description's job is smaller, and it delivers the key safety nuance.

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?

Compact and front-loaded: the resource is stated first, then a dense action list, then the one critical warning. The action enumeration is information-dense but each token earns its place for a multi-action 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 20-parameter, nested-object, 15-action tool with no output schema, the description routes actions adequately and flags the send-confirmation risk, but says nothing about permissions/auth, return shapes for list/get, or what delete destroys. Adequate but with clear gaps.

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

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

Schema description coverage is 75%, so the schema already documents most parameters and the baseline is 3. The description adds only a couple of action-specific hints (kind=newsletter for list, template_id for create) and does not clarify the other ~20 parameters.

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

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

States a specific verb+resource (manage email/SMS campaigns and newsletters) and enumerates all 15 actions, which lets an agent see the scope immediately. It does not explicitly distinguish itself from near-neighbors like sms_send, email_send, or campaigns_analytics, so sibling differentiation is only implied.

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

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

Provides real context for the tricky actions: 'list (kind=newsletter for newsletters)', 'create (draft; template_id starts a newsletter from newsletter_templates)', and 'send_now/schedule/resume message real people: confirm first'. It stops short of naming alternatives (e.g. when to use sms_send instead) or listing 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 already declare this is a read-only, idempotent, non-destructive, closed-world operation, so the safety profile is covered. The description adds genuinely new behavioral context: results come back in order and the shape of each record. It omits whether results are paginated or scoped per pipeline, which is a minor gap.

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

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

Two short sentences, zero filler, with the core action first and the usage cue second. Nothing could be removed without losing information.

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

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

With no parameters and no output schema, the description usefully documents the returned fields and their ordering. It is complete for calling the tool, though it does not say whether the list is global or pipeline-scoped.

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 takes zero parameters, so the schema imposes no semantic burden and the baseline is 4. The description's field list compensates for the absent output schema rather than adding parameter meaning.

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

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

States a specific verb and resource ('List pipeline stages') and enumerates the returned fields (id, name, colour, position), which cleanly separates it from sibling deal_stages_create/deal_stages_update and from deals_list.

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

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

Gives explicit timing guidance ('Call before creating or moving a deal'), which tells the agent when this tool is relevant. It does not name alternatives or state when not to use it, so it falls short of a full when/when-not/alternatives treatment.

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 cover the safety profile (readOnly=false, idempotent=false, openWorld=true, destructive=false), and the description adds value beyond them: the default mailbox is the oldest account, the 50-recipient ceiling across to+cc+bcc, merge-tag/threading behavior, and the confirm-first expectation. It does not spell out auth/permission requirements or what a failure returns, so not a 5.

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

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

Four tight sentences, front-loaded with the core action and scoped by mailbox, followed by body, contactId, recipient-limit, and confirmation guidance. Dense and purposeful, with no filler.

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

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

With no output schema and 12 params at 42% coverage, the description carries a lot but covers the key behavioral facts: default mailbox, threading/merge tags, recipient ceiling, and confirmation. Minor gaps remain (fromName intent, scheduling semantics), but the agent has enough to call it correctly.

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

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

Schema coverage is low (42%) and 12 params exist, so the description must compensate. It clarifies that bodyHtml and bodyText are alternatives and explains the contactId effect, but leaves fromName, cc/bcc/subject, and several others unaddressed, so it only partially fills the gap.

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

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

States a specific verb and resource ('Send a real email from the user's connected mailbox') and the 'real' qualifier plus the mailbox scope clearly separates it from sibling senders like sms_send, invoices_send, and quotes_send. An agent can identify the action without opening the schema.

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

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

Gives concrete usage conditions: supply bodyHtml and/or bodyText, pass contactId for merge tags and threading, and 'Confirm with the user first'. It sets context but does not name alternative tools or state when not to use it, so it falls short of full alternative routing.

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

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

Annotations already flag destructiveHint=true and non-idempotent, but the description adds material context beyond them: the signing/token URL is returned only once and cannot be reshown, and delete immediately stops the endpoint from accepting posts. These are non-obvious behavioral traits an agent must communicate.

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?

Dense and front-loaded: identity/scope first, then the action list, then critical caveats. Nearly every clause earns its place, though the multi-clause second half could be slightly tighter.

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 complex 9-param tool with nested mapping objects and no output schema, the description covers the highest-risk behaviors (one-time token, destructive delete). It leaves ipAllowlist/mapping semantics to the well-documented schema, which is reasonable.

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 78%, near the high-coverage baseline, and the nested mappingJson/mappingMode fields are already documented in the schema. The description contributes no additional parameter meaning beyond restating the action set, so the baseline 3 applies.

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

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

States a specific verb+resource ('Inbound webhooks: URLs other services POST to so Groundbase creates contacts, deals, tasks') and enumerates the operations. It also implicitly distinguishes itself from the sibling outbound_webhooks_manage by naming the inbound direction.

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?

Per-action guidance is present ('create returns the token ONCE', 'delete ... confirm first'), which helps the agent act correctly. However, there is no explicit when-to-use/when-not guidance versus alternatives such as outbound_webhooks_manage; usage is only implied.

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

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

Annotations already declare readOnlyHint, idempotentHint and destructiveHint=false, so safety is covered. The description adds value by enumerating what the listing contains (name, slug, duration, availability, questions) and disclosing the Google Calendar connection status and why (busy times kept free).

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

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

Two tight sentences, zero waste, purpose front-loaded before the secondary Calendar detail. Each clause carries distinct information.

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

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

With no output schema, the description carries the return-value burden, and it does so by listing the key fields. It stops short of describing pagination or ordering, but for a parameterless read tool this is nearly complete.

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

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

The tool takes no parameters, so per the baseline there is nothing to document; schema coverage is 100% and empty. Full credit baseline applies minus nothing of note.

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

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

Specific verb (List) plus resource (booking meeting types) and a clarifying gloss ('the public links people book through'). This clearly separates it from siblings meeting_types_create/update/delete.

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 read-oriented role is implied by 'List', but there is no explicit statement of when to call this versus meeting_types_create/update/delete or other listing tools. Usage is inferable rather than stated.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, so the safety profile is covered. The description adds the mutual-exclusivity rule but says nothing about pagination behavior or result shape, so it adds only modest context beyond structured data.

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

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

A single tight sentence with the key constraint in parentheses, front-loaded after the verb+resource. No wasted words.

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

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

For a 5-parameter list tool with no output schema and 0 required parameters, the description covers the critical selection rule but omits pagination defaults/limits interaction and expected return content. Adequate but with visible gaps.

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

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

With schema description coverage at only 20%, the description carries real weight by clarifying that the three ID parameters are mutually exclusive and one is required — a constraint the schema does not express. It leaves limit/offset semantics to the schema, so it compensates without being complete.

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

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

States a specific verb (list) and resource (notes) along with the three entity types they attach to. It doesn't explicitly name sibling tools, but the CRUD siblings (notes_create/update/delete) make the scope 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?

Gives a concrete usage constraint: pass exactly one of contactId/companyId/dealId. That is clear invocation guidance, though it doesn't state when to prefer this over other read tools or mention prerequisites/permissions.

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 adds substantial behavioral context beyond the annotations: it discloses that create returns the signing secret ONCE, that create/new URL sends CRM data (names, emails, phones) externally, that the owner gets emailed, and that delete stops deliveries and abandons retries. These are critical operational details not captured in 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 dense but front-loaded and highly structured: it opens with the core mechanism, then action list, then critical behavioral warnings in order of importance. Every sentence adds distinct value with no redundancy.

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

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

Without an output schema, the description compensates by explaining what create returns (signing secret ONCE) and what delete does (stops deliveries, abandons retries). It covers the full CRUD lifecycle, external side effects, confirmation requirements, and security implications—complete for a mutation tool with destructive capabilities.

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 71%, but the description adds critical meaning: it explains that create returns the signing secret once, emphasizes confirming the URL with the user, and notes that URL should be https because payload is CRM data. It contextualizes the events parameter's role and the create/update schema requirements.

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+resource combination: Groundbase POSTs to a URL when subscribed events fire, with actions clearly enumerated. It distinguishes itself from the sibling inbound_webhooks_manage by specifying outbound direction and the POST-to-URL mechanism.

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 action routing (list | get | create | update | delete) and specifies that create requires name, url, and events. It includes critical confirmation guidance ('confirm the url with the user first' and 'confirm first' for delete) but doesn't explicitly state when NOT to use this tool for certain scenarios.

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 safety (readOnlyHint, idempotentHint, destructiveHint=false), so the description's main contribution is return-shape context: counts per status, open value per currency, and single-quote lines/totals/deposit/acceptance details. It does not mention pagination, permissions, or rate limits, but it adds useful behavioral detail 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 front-loaded sentence with no wasted words, presenting list mode first and the id-based detail mode second. Every phrase contributes to either behavior or invocation.

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 list/detail tool with no output schema, the description does supply return values for both modes and annotations cover safety. However, it omits any explanation of companyId/contactId filtering, and it provides no pagination or scope expectations, so an agent lacks some context needed to use the filtering parameters confidently.

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

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

Schema description coverage is 50%; id and status are documented in the schema, while companyId and contactId have no descriptions anywhere. The description reinforces the id mode and adds return detail, but it never explains companyId/contactId filtering, leaving a substantial semantic gap for two of four parameters.

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 specific verb 'List' and resource 'quotes', and distinguishes two modes: aggregate listing and single-quote retrieval by id. It is clearly a read/list operation amid quote-mutating siblings such as quotes_send and quotes_void.

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

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

It gives clear context for two invocation modes: omit id for status/count/value aggregation, or pass id for one quote with line-level detail. It does not explicitly name when to avoid this tool or point to an alternative, but no sibling provides a competing quote-list capability.

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 cover the safety profile (destructiveHint=true, openWorldHint=true, non-idempotent). The description adds value beyond that: disconnect 'wipes credentials,' enable_tracking installs a webhook, test_send sends a real email, and the confirmation warning for destructive actions. A genuine addition over 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?

Tight and front-loaded: the identity sentence leads, actions are enumerated compactly, then safety/confirmation notes. Every clause carries non-redundant information; no filler.

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

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

Covers the multi-action tool well: which action does what, destructive-action confirmation, and the app-only connection constraint. Without an output schema, it should describe return shape for status/domains/test_send, which it does not, leaving a minor gap.

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

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

Schema coverage is only 20%, so the description must partially compensate. It names 'to' for test_send and the from_email concept, and clarifies that action selects among five named behaviors, but html, text, and subject are undocumented anywhere. Baseline 3 with a partial gap remaining.

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

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

States what the tool is (BYO Resend connection management) and enumerates all five actions with parenthetical detail (enable_tracking installs webhooks, domains shows verification state). This clearly distinguishes it from siblings like email_send or sending_settings, but the top-level purpose is framed as a noun phrase rather than a single verb+resource.

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

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

Provides explicit procedural guidance: check domains before choosing from_email, confirm disconnect and the test_send address first, and connecting happens only in-app never by pasting a key. Strong when/why context. No explicit exclusions against, e.g., email_send for sending actual campaign mail, so it falls short of 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 declare readOnlyHint=true, idempotentHint=true and destructiveHint=false, so the safety profile is fully covered. The description adds useful domain context by defining saved views as named filters, but says nothing about return shape, ordering, or pagination.

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

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

One efficient sentence with the resource and clarifying definition front-loaded; nothing is wasted, though the definition could be slightly more informative for the same length.

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

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

For a simple read-only list tool with one optional parameter, full schema coverage, and annotations covering safety, the description supplies what an agent needs. No output schema exists, so return values need not be described.

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

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

Schema coverage is 100% with a single optional enum parameter that the schema fully documents. The description's enumeration of 'contacts, companies, deals or tasks' mirrors the enum rather than adding new semantics, so the baseline 3 applies.

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

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

States a specific verb (List) and resource (saved views), and the parenthetical defines what a saved view is and which entity types they cover. It is clearly distinguishable from saved_views_create and saved_views_delete, though it does not explicitly name those siblings.

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

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

Usage is only implied: the agent can infer this is the read tool for saved views, but there is no explicit when-to-use guidance, no mention of prerequisites, and no routing to alternative tools such as listing contacts or deals directly.

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

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

Annotations only give the generic safety profile (readOnlyHint=false, destructiveHint=false), so the description carries most of the load. It discloses non-obvious behavior: null=none, 0=stop today, that over-cap recipients wait for later days, and that the cap applies in the account timezone. It doesn't explain reversibility or auth/permission requirements, but the added context is substantial.

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

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

The definition is dense but well front-loaded, opening with the resource, then get semantics, then set semantics, then usage. Most sentences earn their place, though the get/set token lists are tightly packed and could be marginally cleaner.

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 helpfully enumerates what get returns, and it covers behavior and value semantics for all three parameters. Given no output schema exists it is nearly complete; only auth/permission context and the read/write split of the mixed get/set action are left unstated.

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 67%, and the description meaningfully extends it: it clarifies the two get/set actions, that 'domain' scopes to one domain vs account-wide, and the null/0 semantics of daily_email_send_cap. It also documents the get return values (cap, sent_today, remaining_today, domain_caps), which the schema does not cover.

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 resource (daily cap on campaign EMAILS) and explicitly disambiguates it from the sibling SMS tools with '(not SMS)'. It also spells out both get and set behaviors, so an agent can tell exactly what this manages without opening the schema.

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

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

It gives a concrete use case ('Use to warm a new domain (~20/day)') and implicitly routes email-cap concerns here rather than to sms_send/sms_optouts. However, it doesn't state explicit when-not conditions or the exact prerequisite for setting a domain cap beyond the parameter description.

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

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

Annotations only declare the generic write/openWorld/non-idempotent profile; the description adds material behavior the annotations do not: it sends a real message, is cost-bearing ('billed per segment on the user's own Twilio account'), and requires user confirmation. These are exactly the traits an agent needs before invoking a non-idempotent outbound send.

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

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

Two compact sentences, front-loaded with the action and its scheduling variant, then the cost/confirmation caveat. Every clause earns its place with no filler.

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

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

For a non-idempotent outbound send with annotations covering the safety profile and no output schema, the description covers cost, timing, and the confirmation requirement. It stops short of noting delivery-failure or opt-out handling, which would complete the picture.

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 already 80%, with toPhone, contactId, fromNumber, and scheduledAt all documented in the schema. The description only reinforces the scheduledAt meaning, adding little beyond what structured fields provide, so the baseline 3 applies.

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

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

States a specific verb and resource ('Send a text') and adds the scheduling dimension ('now, or later with scheduledAt'). It is clearly distinguishable from sms_list and sms_cancel_scheduled by its resource and action, though it does not explicitly name those siblings.

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

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

Gives a concrete usage directive: 'confirm with the user first,' which tells the agent this is a user-approval-gated action. It also clarifies the now-vs-later condition via scheduledAt, but states no when-not-to-use or explicit alternatives.

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

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

Annotations already provide a complete safety profile (readOnlyHint, idempotentHint, destructiveHint=false, openWorldHint=false), so the description does not need to restate safety. It adds only that results are scoped to the user's tags and include ids, which is modest context 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, front-loaded sentence that states the action and return content with no wasted words. It is appropriately sized for a simple list operation.

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 list tool with no output schema, the description covers the core action and says ids are returned. However, it omits return shape details such as ordering, pagination, or whether additional tag metadata is included, and it does not distinguish this from merge_tags_list.

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

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

The tool has zero input parameters, so there are no parameter semantics to document. The description's mention of 'ids' refers to returned tag identifiers rather than inputs, and the baseline for a parameterless tool is 4.

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 ('List'), resource ('tags'), and scope ('user's tags'), and adds that ids are included. It clearly separates the tool from create/update/delete/apply tag operations, but does not differentiate it from the sibling merge_tags_list tool.

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

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

The description gives no explicit when-to-use guidance, no conditions or exclusions, and does not point to alternatives such as merge_tags_list. Usage is only implied by the verb '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, idempotentHint, and destructiveHint=false, so the safety profile is covered. The description adds the returned field set (name, body, subject), which is genuinely useful, but says nothing about pagination, limits, or ordering for a list operation.

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

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

A single sentence that front-loads the list behavior and appends the fetch-by-id variant. No filler, no 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?

With no output schema, the description compensates by naming the returned fields, and the safety profile is carried by annotations. Minor gaps remain around list size, ordering, and pagination for a tool whose primary job is enumeration.

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 both parameters are already documented with the same semantics ('Returns that one template', 'Omit for both'). The description largely restates the schema, so baseline 3 applies.

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

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

States a specific verb (List) and resource (SMS/email templates), names the fields returned, and covers the single-fetch mode in the same sentence. An agent can distinguish this from templates_create/update/delete without opening the schema.

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

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

It gives in-tool guidance (pass `id` to fetch one; type enum 'omit for both') but no routing guidance relative to templates_create, templates_update, or templates_delete. Usage is implied by the verb rather than stated as when/when-not.

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 safety (readOnlyHint, idempotentHint, destructiveHint=false), but the description adds real behavioral context beyond them: newest-first ordering, aggregate outputs (running timer, per-customer totals), the 30-day default span, and a definition of the 'unbilled' status. It omits pagination behavior and the limit interaction with results.

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

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

Two dense sentences, front-loaded with what is returned and how it is ordered, followed by the non-obvious status semantics. No filler.

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

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

Without an output schema, the description must describe returns, and it does (entries, running timer, totals). Default window and ordering are covered; only pagination/limit behavior and the role of the ID filters remain missing for a 7-param read tool.

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

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

Schema coverage is 57%, with three ID filters (dealId, companyId, contactId) and limit undocumented in both places. The description compensates partly by explaining the 'unbilled' enum value and implying the default last-30-days semantics for from/to, but leaves the remaining filters unexplained.

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

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

Specific verb (List) and resource (time entries) with scoping detail: newest-first ordering, inclusion of the running timer and per-customer totals, and a default 30-day window. It does not explicitly contrast itself with siblings like time_log or time_update, but the resource is unambiguous.

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

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

Usage is implied (a read/list tool for time entries) and a sensible default window is given, but there is no explicit when-to-use guidance or naming of alternatives such as time_log, time_update, or time_timer_start/stop. An agent must infer the 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?

The annotations only declare the generic safety profile (readOnlyHint=false, openWorldHint=true, idempotentHint=false, destructiveHint=false). The description adds behavior the annotations cannot convey: the call hangs up if a human answers, it bills at Twilio voice rates on the user's account, it is geo-restricted to US/Canada, and the user must confirm first.

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

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

Three tight sentences, front-loaded with the core action and its key side effect (hang-up on human answer), followed by cost/geo constraints and invocation guidance. Nothing is padded or repeated from the schema.

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

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

For a non-idempotent, world-affecting outbound action with no output schema, the description covers the mechanism, the human-answer behavior, the billing consequence, the geo boundary, and the confirmation requirement. Nothing material an agent needs before calling 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%, so the baseline is 3. The description adds value by clarifying that contactId and toPhone are the two mutually alternative recipient paths ('Give contactId or toPhone'), which the schema lists as independent properties without stating the either/or relationship.

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

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

States a specific verb and resource ('Play a drop onto someone's voicemail via a real Twilio call') and immediately distinguishes this tool from the CRUD siblings voicemail_drops_create/update/list/delete by describing the actual action rather than a record operation. An agent can tell what it does without opening the schema.

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

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

Gives concrete invocation guidance ('Give contactId or toPhone') and an explicit procedural requirement ('Confirm with the user first'), plus a hard eligibility constraint (US and Canadian numbers only). It stops short of naming a specific alternative tool or a when-not-to-use case, but the context is clear.

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

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

Annotations already declare readOnlyHint, idempotentHint and destructiveHint=false, so the safety profile is covered. With no output schema, the description usefully enumerates the fields the agent will receive (name, has_audio, duration_ms, source, script_text) and flags the domain constraint that only drops with audio can be used by voicemail_drops_drop. It omits ordering, pagination, and volume behavior, keeping this below a 5.

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

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

A single sentence, verb-front-loaded, with every element carrying information and no filler. The parenthetical aside about has_audio slightly interrupts the field enumeration but adds genuine value.

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

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

For a no-parameter list tool with no output schema, the description supplies the essential return field set, which is the main gap it needed to fill. However it says nothing about result volume, ordering, or whether results are paginated, which an agent calling a list endpoint would benefit from knowing.

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 takes zero parameters, so the baseline is 4. The field list in the description refers to returned data rather than inputs, which is appropriate for a parameterless lister.

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

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

States a specific verb (List) and resource (voicemail drops), and is easily distinguished from the sibling mutations voicemail_drops_create/delete/drop/update. It does not explicitly say it returns all drops in the account or how it relates to the other voicemail tools, so it stops just short of a 5.

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

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

There is no when-to-use guidance, no mention of prerequisites, and no references to alternative tools such as voicemail_drops_drop despite that tool being directly related ('only drops with audio can be dropped'). The agent must infer the role of this tool from its name 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 already declare readOnly/idempotent/non-destructive, so the safety profile is covered. The description adds real behavioral context beyond that: run history is newest-first and includes per-step results explaining skips and failures. It stops short of describing pagination or limits, but adds meaningful return-context.

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

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

Two sentences, both dense with useful routing information, with the base list behavior front-loaded before the conditional modes. No filler.

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

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

For a read-only list tool with full schema coverage and no output schema, this description covers the primary modes, ordering, and content of results well. Minor gap: it never mentions the `limit`/pagination behavior, which the agent must infer from 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?

With 100% schema coverage the baseline is 3, but the description goes further by explaining the interaction between `id` and `runs: true` and the ordering/content of run output, which the schema only states tersely ('With id: return run history instead'). It does not mention the `limit` parameter, leaving that entirely to the schema.

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

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

The description opens with a specific verb and resource ('List workflows') and enumerates the returned fields (trigger, step count, active state, last run). It clearly distinguishes the three usage modes (all workflows, one full definition, run history) so an agent can identify the tool unambiguously among siblings like workflows_create/delete/run_now.

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

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

It gives explicit conditional instructions: pass `id` for a single workflow's definition and `id` plus `runs: true` for run history. It does not state when *not* to use it or name alternatives, but the mode-selection guidance is clear and actionable.

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

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

Annotations already flag it as a non-read-only, non-idempotent, open-world action, and the description adds critical undisclosed impact: steps really execute real-world texts, emails, and webhooks. The confirm-with-user warning is exactly the behavioral context an agent needs beyond the structured hints.

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

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

Two tight sentences, front-loaded with the action and immediately followed by the safety-relevant consequence. Zero wasted words.

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

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

For a mutation tool with annotations and no output schema, the description covers the action and its real-world side effects well. The main gap is parameter clarification, but overall an agent has enough to invoke it safely.

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

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

Schema description coverage is 0%, so the description must carry the load, but it only implies 'one existing record' without clarifying that 'id' is the workflow id or that entityType/entityId designate the target record. It leaves the three required params largely unexplained.

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

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

States a specific verb (Run) and resource (workflow) with clear scope: on one existing record, bypassing its trigger. This distinctly separates it from the sibling workflows_create/list/update tools, which manage workflow definitions rather than executing one.

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?

Conveys the trigger context (running now bypasses it) and instructs the agent to confirm with the user first, which is real usage guidance. It stops short of naming explicit alternatives or when-not-to-use conditions, but the context is clear.

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