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

The description discloses the critical dry-run behavior: without confirm:true, the tool returns a preview and makes no network call. This adds valuable context beyond the readOnlyHint=false annotation, which indicates mutation potential. The annotation and description are consistent.

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 long, front-loaded with the main action, and contains no filler. Every sentence adds value.

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

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

For a simple action tool with rich schema annotations and no output schema, the description is largely complete. It covers the key behavioral nuance (dry run vs. actual send) that an agent needs to know before invoking. It could potentially mention when to use this over sibling tools, but the absence is not critical given the tool's straightforward purpose.

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 already covers all four parameters with detailed descriptions, including the confirm flag's role. The description's mention of confirm:true reinforces the schema but doesn't add new parameter-level detail. With 100% schema coverage, the baseline of 3 is appropriate.

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

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

The description clearly states the tool sends a message to Crown Town Compost customer support, using a specific verb and resource. It distinguishes from sibling tools like report_missed_pickup and skip_service by focusing on general support contact.

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 mention when to use this tool versus alternatives such as report_missed_pickup or skip_service. However, the intended use is implied by the verb 'send a message to customer support,' and the dry-run note clarifies how to safely test the tool.

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

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

Annotations already cover readOnlyHint, openWorldHint, and idempotentHint, so the read-only behavior is not new information. The description adds mild context about the data scope (the caller's own account) and redirects mutation use cases, but does not disclose additional behavioral traits such as response format, auth requirements, or rate limits. No contradiction with annotations exists.

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 tight sentences with no filler. The primary purpose is front-loaded, the field list is specific, and the read-only/alternative routing is delivered in a short second sentence. Every part 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?

The tool has only one optional parameter with high schema coverage, and the description names the returned data categories. The lack of an output schema is partly mitigated by listing the fields, though it does not explicitly describe the response envelope. Overall, the agent has enough to call it correctly without confusion.

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 view parameter is thoroughly explained in the schema itself, including what compact versus full returns and what compact strips. The tool description adds no param-specific guidance, but with full schema coverage the baseline of 3 is appropriate.

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

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

States a specific verb (get), a clear resource (account contact details), and the specific fields returned (first name, last name, phone, notification preferences). It also distinguishes itself from the sibling crowntown_update_account by explicitly naming the alternative.

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

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

Explicitly says the tool is read-only and directs the agent to crowntown_update_account when changes are needed. This gives clear when-to-use and when-not-to-use guidance, leaving no ambiguity about choosing between the read and update tools.

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

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

The description adds value beyond the readOnlyHint annotation by detailing the exact data returned (e.g., plan, price, renewal date, environmental impact). It confirms the read-only nature, aligning with annotations, and clarifies the scope of the dashboard.

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 with a clear front-loaded verb and resource, followed by a compact list of dashboard components. It is information-dense without superfluous 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?

The description fully covers the tool's purpose and return content, which is essential given the absence of an output schema. It provides enough context for an agent to decide when to invoke it and what to expect.

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 the schema provides complete coverage and there is nothing to document. The description correctly omits parameter details, meeting the baseline for 0-param tools.

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

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

The description clearly states the verb 'Get' and the resource 'dashboard summary', and enumerates the specific contents (account status, subscription details, service dates, addresses, environmental impact). This distinguishes it from sibling tools like 'get_account' or 'list_service_history'.

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

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

The description implies this is a high-level summary tool through its list of aggregated data, but it does not explicitly state when to use it over alternatives or mention exclusions. No direct comparison to sibling tools is provided.

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

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

Beyond the readOnlyHint and idempotentHint annotations, the description adds valuable context: it explicitly states Crown Town Compost publishes no guaranteed arrival window, so the window is empirical and derived from recorded collection times. This explains the tool's behavior and data provenance, exceeding what annotations alone convey.

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

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

The description is two concise sentences, front-loaded with the primary outcome and enriched with necessary caveats. Every sentence contributes meaning, with no redundant or filler content.

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

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

Despite lacking an output schema, the description enumerates exactly what is returned (pickup days, next service date, set-out time, observed window with earliest/latest/typical and consistency). It also covers the empirical derivation and absence of guaranteed times, making the tool's behavior fully understandable in context.

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

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

The input schema fully documents history_sample with a clear description, type, default, and bounds. The tool description does not mention the parameter, but since schema coverage is 100%, the baseline of 3 is appropriate; no additional semantic value 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 clearly states the tool fetches the pickup schedule for each service address, listing the exact elements returned (pickup days, next service date, set-out time, observed arrival window). This specific verb+resource combination distinguishes it from sibling tools like list_upcoming_services, which focus on individual upcoming services rather than the recurring schedule.

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 clear context on what the tool returns, implying when to use it (when you need the schedule and arrival-time window). It does not explicitly name alternatives or exclusions, but the behavioral detail about the observed window makes its purpose obvious relative to siblings.

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

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

Beyond the readOnlyHint and idempotentHint annotations, the description adds valuable behavioral context: it explains the login step, dashboard fetch, and the specific output fields (authenticated, account_status, service_addresses). It also reveals the error-handling nuance of distinguishing 'no creds', 'bad creds', and 'site error', which annotations do not cover.

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 action and compactly lists the output and error distinctions. It includes no filler and every phrase contributes 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?

The tool has no output schema, but the description explicitly enumerates the return fields and the plain-English hint types. It covers the key behavioral aspects (read-only, auth check, portal access) sufficiently for a tool of this simplicity, and no additional details are necessary.

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 zero parameters, the description adds no parameter-specific semantics, but the baseline for 0 params is 4. The tool requires no input, so the description's behavior description fully covers what the agent needs to know about invoking it.

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 action: confirming credentials, logging in, fetching the dashboard, and reporting a structured result. It distinguishes itself from siblings like crowntown_get_account or crowntown_get_dashboard by focusing on health verification rather than data retrieval or mutation.

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 implicitly communicates when to use the tool: as a healthcheck/auth verification before performing other portal operations. However, it does not explicitly mention alternatives or when not to use it, so it falls short of a 5.

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

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

Annotations already declare readOnlyHint, openWorldHint, and idempotentHint. The description adds behavioral context beyond these: it notes pagination, lists the response fields (including links to Stripe PDF/receipt/hosted invoice page), and explicitly states 'Read-only' (redundant but consistent). This helps the agent know what to expect from the output.

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, information-dense sentence followed by two short labels ('Paginated. Read-only.'). Every word adds value, and the key purpose is front-loaded. No fluff.

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 is simple with 3 optional, well-documented parameters. No output schema, but the description enumerates all returned fields and notes pagination. Annotations cover safety and determinism hints. This is complete for an agent to invoke correctly.

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

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

Schema coverage is 100% with descriptions for each parameter (page, per_page, payable_only). The description adds no parameter-specific semantics beyond mentioning pagination and 'whether payable', which are already covered. Baseline 3 is appropriate when the schema does the heavy lifting.

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

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

The description states a specific verb and resource: 'List your Crown Town Compost invoices', and enumerates the exact fields returned (number, date, amount, status, payable, links). This clearly distinguishes it from sibling tools like list_service_history or list_upcoming_services.

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: any time the user needs billing/invoice history. It does not explicitly mention alternatives or exclusions, but the context is clear and no sibling tool overlaps, so the guidance is adequate.

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

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

Annotations already declare readOnlyHint=true and idempotentHint=true, so the read-only nature is covered. The description adds behavioral context by mentioning pagination, filtering by status, and listing the specific status values, which goes beyond the annotations. No contradiction exists.

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

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

The description is concise with three short sentences that cover purpose, returned fields, and pagination/filtering. It wastes little space, though the status enum is somewhat redundant with 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?

Since there is no output schema, the description's enumeration of returned fields (date, status, collection time, weight, services rendered) is essential and well-provided. Combined with pagination, filtering, and the read-only annotation, the tool is fully contextualized for a list operation.

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

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

Schema coverage is 100%, meaning each parameter (page, status, per_page) already has a clear description. The description only redundantly mentions status filtering and provides no additional parameter detail 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 states 'List past collection stops for your account' with a specific verb and resource, and explicitly says 'past' to distinguish from the sibling 'list_upcoming_services'. It also enumerates the returned fields, making the purpose unmistakable.

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 clearly indicates this is for historical collection stops, which contextually differentiates it from the upcoming-services sibling. However, it does not explicitly name alternatives or state when not to use this tool, so it stops short of full usage guidance.

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

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

Annotations already provide readOnlyHint, openWorldHint, and idempotentHint, reducing the burden on the description. The description adds useful behavioral context: output includes both scheduled and already-skipped services, and it pulls from the service calendar. It also repeats 'Read-only' reinforcing safety, though it doesn't discuss pagination or ordering—acceptable for a simple list tool.

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

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

Two sentences, front-loaded with the verb and resource, no wasted words. The first sentence describes scope and output; the second gives clear usage guidance. Perfectly sized for the tool's simplicity.

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 no parameters, no output schema, and helpful annotations, the description fully covers purpose, return content, and alternative tools. It is complete for an agent to select and invoke correctly, with no significant 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 zero parameters, the schema has no properties to explain, so baseline 4 applies. The description does not need to add parameter details and correctly focuses on output semantics instead.

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

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

The description clearly states the tool lists upcoming scheduled collection days from the service calendar, specifying the output includes skip identifiers (rid, clid), service date, and skip status. This distinguishes it from siblings like list_service_history (past services) and skip_service (mutation). The verb 'List' and specific resource 'upcoming services' make the purpose unambiguous.

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

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

The description explicitly directs users to use crowntown_skip_service for skipping/unskipping, establishing a clear alternative and when this read-only tool is appropriate. It also implies use when needing identifiers to skip, giving practical guidance beyond basic purpose.

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 goes beyond annotations by disclosing that without confirm:true it is a dry run that makes no network call, and that with confirm:true it notifies staff. This is key safety behavior not captured by readOnlyHint or openWorldHint.

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 purpose, and contains no filler. The dry-run caveat is essential and placed at the end, keeping structure efficient.

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

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

The tool has no output schema, but the description covers purpose, notification outcome, and dry-run behavior. It doesn't detail preview contents or the confirmed response, but for a simple report tool 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?

Schema coverage is 100%, and the description adds no meaning beyond the schema's parameter descriptions. It repeats the confirm dry-run behavior already present in the confirm property 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 uses a specific verb ('Report') plus a clear resource ('scheduled collection') and scope ('missed'), and states the outcome (notifies staff). It distinguishes from sibling tools like crowntown_skip_service by focusing on reporting a missed past collection.

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 (when a scheduled collection was missed) but does not explicitly differentiate from alternatives like skip_service or contact_support. The dry-run guidance is useful for safe invocation but not for tool selection.

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

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

Beyond the annotations (readOnlyHint=false, openWorldHint=true), the description discloses a critical behavioral detail: without confirm:true it is a dry run that returns a preview and makes no network call. This adds significant transparency about side effects and execution mode, which the annotations alone do not convey.

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

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

Two concise sentences, front-loaded with the primary action and immediately giving the essential prerequisite. No filler or redundant text; every clause contributes meaningful 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?

The description covers prerequisites and the confirm gating, which is good. However, without an output schema it does not describe the preview format or the final response after a confirmed skip/unskip, leaving a small gap for a state-changing 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 baseline is 3. The description adds a small value by highlighting confirm's dry-run behavior, but mostly reinforces the rid/clid source that the schema already documents. No major enrichment 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?

Description uses a specific verb ('Skip (or un-skip)') with a clear resource ('upcoming collection day'), which distinguishes it from sibling tools like report_missed_pickup and list_upcoming_services. The mention of passing rid + clid from crowntown_list_upcoming_services further grounds the tool's exact role.

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 a key prerequisite (obtain rid/clid from crowntown_list_upcoming_services) and clearly explains the dry-run behavior without confirm:true. It does not explicitly name when-not-to-use or alternatives, but the context is evident from the tool's action and sibling names.

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 reveals key behavioral traits beyond the annotations: it reads the current account form, modifies only the specified fields, re-saves the rest verbatim, and requires confirm:true or else performs a dry run. This is critical for safe usage and fully covers the tool's side effects, especially given annotations only indicate readOnlyHint:false and openWorldHint:true.

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, immediately front-loaded with the tool's purpose, and every clause serves a purpose. No unnecessary filler or repetition.

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

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

The description covers the core operation: reads current form, updates specified fields, re-saves, and explains the confirm/dry-run mechanism. It does not describe the success response or error cases, but given there is no output schema and the tool is moderately complex, the coverage is solid.

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 every parameter already has a description. The description adds context about the selective-field behavior and confirm:true dry-run, but it does not provide per-parameter details beyond what the schema already offers. This aligns with the baseline of 3.

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

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

Description begins with 'Update your contact details and/or notification preferences' – a specific verb (Update) and resource (account), clearly distinguishing it from sibling tools like get_account, list_invoices, and healthcheck. The scope is explicit 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?

Clear context: use this tool when the goal is to change account contact details or notification preferences. It does not explicitly mention alternatives or exclusion scenarios, but the read-modify-write behavior and confirm requirement are clearly stated, giving useful context for when to invoke it.

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