Deer Supply

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

The annotations already declare read-only, idempotent, non-destructive, and closed-world behavior, so the bar is lower. The description adds valuable content beyond that by enumerating exactly what is compared (mechanism, generation, trial weight loss, maintenance dose, prices in CAD), which helps the agent understand the output without an output 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?

The description is two sentences: the first front-loads the comparison scope and fields, and the second gives the usage trigger. It is tight and every element 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 zero-parameter, read-only comparison tool with no output schema, the description provides enough detail about what will be compared and when to use it. No additional behavioral or parameter information is needed for correct invocation.

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

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

The tool has zero parameters, so no parameter semantics need to be documented. Per the rubric, zero parameters yields a baseline score of 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 (side-by-side comparison) and resource (the three GLP weight-loss medications Deer Supply sells), naming each medication and the compared attributes. It is clearly distinguishable from siblings like search_products or get_product, which handle individual products.

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 explicitly says to use this when someone is choosing a weight-loss option, giving clear context. It does not name alternatives or state when not to use it, so it falls short of the highest level.

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 destructiveHint=false, and the description adds meaningful context: the recipient enters their own delivery details and payment, and agents cannot place orders. This is useful workflow/boundary disclosure beyond the annotations, though idempotency and link behavior are left to 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?

A single dense sentence, front-loaded with the artifact and effect, followed by the workflow constraint. No filler or redundancy.

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

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

With no output schema and a single simple param, the description covers the essential purpose and the key operational boundary (agents cannot check out). It omits any hint of the returned link/format, which is 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 description coverage is 0%, so the description must carry the weight, and it only loosely ties the 'items' param to 'already in it.' It does not explain that items are variant_id/qty pairs or any format constraints, but the single param is largely self-describing from 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 names a specific artifact (a deer.supply cart link) and its effect (opens the cart pre-filled with the given items). It clearly conveys the resource and outcome, though it never names a sibling like quote_cart to sharpen the boundary.

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

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

Usage is implied: the link is for the person to review and check out themselves, and 'Agents cannot place orders' sets a boundary on agent behavior. However, there is no explicit when-to-use-this-vs-alternatives routing (e.g., when to use this instead of quote_cart).

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

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

Annotations already declare readOnlyHint, idempotentHint, non-destructive and closed-world, so the safety profile is covered. The description earns credit by disclosing how the estimate is derived: Deer's product-page quotes, a noon Eastern same-day ship cutoff, and fastest-service shipping for pens. It does not address error handling for invalid postal codes, but that is minor given the annotation coverage.

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

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

A single front-loaded sentence that states the purpose first and then the computation rules. Dense but every clause (Canadian postal code, noon Eastern cutoff, pen service) carries information; no filler or repetition.

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

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

For a simple read-only estimate with no output schema, the description supplies the basis of the calculation and the meaning of both inputs, which is enough for correct invocation. It could say more about the shape of the returned dates, but the 'ship and arrive' phrasing covers the essentials.

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 50%: includes_pens is documented in the schema, but postal_code is not. The description partially compensates by specifying the postal code must be Canadian and by explaining the pen-shipping behavior that maps to includes_pens ('pens travel on the fastest service'). It adds meaningful constraint beyond the schema but does not fully cover the undocumented parameter's format.

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

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

The description names a specific computation (ship and arrival dates for an order placed now) and the resource (a Canadian postal code), making it clearly distinct from track_order (existing orders) and get_store_info. It stops short of explicitly naming a sibling to route against, but the hypothetical-new-order framing makes 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?

It clarifies the scenario (an order placed now) and the input domain (Canadian postal code), which implies when to reach for it. However, there is no explicit when-to-use/when-not guidance or named alternative (e.g., 'for an order you already placed, use track_order instead'), leaving the boundary to inference.

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

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

Annotations already declare read-only, idempotent, non-destructive, closed-world behavior, so the safety profile is covered. The description adds genuinely useful context beyond that: the data is sourced from a specific calculator's curves, it is a trial-average rather than a per-person prediction, and the time horizons returned are 6, 12 and 18 months.

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?

Roughly two sentences, front-loaded with the core computation and followed by the essential caveat. Every clause earns its place and nothing is padded.

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 returns; it does so adequately by naming the metric and the 6/12/18-month timepoints. A brief note on whether results are per-medication rows or a single curve for the supplied weight would close the remaining ambiguity.

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

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

Schema coverage is 50%: 'weight' is described as current body weight, while 'unit' carries only an enum and default with no prose. The description adds the notion of a 'starting weight' but does not clarify the unit parameter or how weight/unit interact, so it neither fully compensates for the gap nor is redundant.

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

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

The description names a specific computation (trial-averaged weight loss at 6/12/18 months for a given starting weight) rather than restating the name, so an agent knows exactly what question it answers. It does not, however, contrast itself against the obvious sibling compare_weight_loss_medications, and the phrase 'per medication' is slightly at odds with a schema that has no medication parameter.

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

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

Usage is implied by 'the same curves as deer.supply/calculator,' which tells the agent this is a population-average estimator rather than a personalized forecast. There is no explicit when-to-use/when-not guidance and no pointer to compare_weight_loss_medications for the multi-drug case.

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

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint=false, so safety and determinism are covered by structured data. The description adds useful scope behavior: empty input returns the entire FAQ, and the response includes policy links, which the annotations 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 sentences, no filler, topic scope front-loaded and the invocation instruction trailing. 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 simple read-only lookup with one optional parameter and no output schema, the description covers purpose, inputs, and return content (FAQ answers + policy links) adequately. It does not describe response shape or whether answers are verbatim, but that is a modest gap given the tool's simplicity.

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

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

Schema coverage is 0% and the single 'question' property has no schema description, so the description must compensate — and it does, explaining what to pass and what an empty value means. It stops short of stating whether partial/whole-FAQ output is paginated or truncated.

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 ('answers from Deer Supply's FAQ... plus links to its policies') and enumerates covered topics (shipping, storage, payment, pens, eligibility, returns). No sibling tool offers FAQ or policy lookup, so an agent can route to it unambiguously against get_store_info or get_product.

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 usable invocation guidance — 'Pass the question; leave it empty for the whole FAQ' — which tells the agent both the normal path and the no-argument path. It lacks explicit when-not guidance or named alternatives, but no sibling overlaps this function, so that gap is minor.

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

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint=false, so the safety profile is fully covered. The description adds one useful behavioral fact — reports are third-party COAs published at product-size granularity — but says nothing about return format, availability, or coverage gaps. With annotations carrying the behavioral load, a 3 is appropriate.

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

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

Extremely short with the resource stated first and no filler, which is good front-loading. But the brevity comes from under-specification rather than efficiency, and the fragmentary grammar makes the intent harder to parse than a single well-formed sentence would.

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 lookup tool with no output schema, the description should at least indicate what a caller gets back (COA documents, links, per-size rows) and how product_id is sourced. Neither is present, so an agent cannot predict the response shape or construct a valid identifier.

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% for the single product_id parameter, so the description must compensate and does not: it only restates that product_id is optional, adding no format, source, or example. An agent still does not know whether product_id is a slug, SKU, or internal ID.

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

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

The description names a specific resource — third-party lab (COA) reports published per product size — so an agent can tell what it retrieves. However it is a sentence fragment with no verb, and it does not distinguish itself from sibling tools like get_trust_report or get_product that may also surface product documentation.

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?

'Optional product_id' implies a filter-or-all behavior, which is minimal implicit guidance. There is no explicit when-to-use context, no statement of when to prefer this over get_trust_report or get_product, and no note on whether product_id must come from search_products.

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 and non-destructive, so the safety profile is covered. The description adds real context beyond them: the auth requirement and the conditional gate that health-profile detail appears only 'when health access was granted'. No output schema exists, and the return contents are summarized rather than structurally described, which keeps this short of 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?

Front-loaded with the auth prerequisite, then a single dense sentence enumerating the payload, closed with a two-word directive. 'The same picture the store's own assistant has' is mildly redundant with 'plain-language summary' but does convey data parity, so the sentence still earns its place.

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

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

With no output schema and no parameters, the description carries the full burden and meets it: it states the auth requirement, enumerates the returned data, and flags the conditional health-data gating. An agent needs nothing further to decide to call it and understand what comes back.

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 there is no parameter semantics to document; baseline 4 applies. The description correctly implies the customer identity is derived from the signed-in session rather than passed in.

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

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

Names a specific resource (the signed-in customer's Deer account) and enumerates its exact scope: name, orders with status and tracking, store credit and rewards, and health-profile weigh-ins, plan and side effects. The aggregate framing plus 'Start here' positions it against narrower siblings like list_my_orders and get_my_health without the agent needing to open any 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?

'Start here' gives explicit entry-point guidance and 'Requires signing in with a Deer account' states the precondition. It does not name when to prefer the narrower siblings (list_my_orders, get_my_health, get_lab_results) over this aggregate, so routing for sub-queries is left to inference.

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

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

Annotations already declare readOnlyHint, idempotentHint, non-destructive, and closed-world, so the safety profile is covered. The description adds genuinely new context: an authentication requirement and the fact that one sign-in can chart several people (multi-profile behavior), which the annotations 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?

It is a single dense colon-list sentence, but it is front-loaded with the auth prerequisite and every clause describes a distinct returned field rather than padding. Slightly run-on, though no sentence is wasted.

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

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

With no output schema, the description does the heavy lifting by enumerating the returned data (ids, weigh-ins in pounds and trend, treatment plan fields, side effects with ids, reminders, reward). It is close to sufficient for an agent to consume the result, missing only detail on formats such as how 'the trend' is represented.

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 description appropriately spends no space on parameter syntax and instead documents the shape of what comes back.

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 makes clear this returns the signed-in user's health profiles and enumerates their contents (weigh-ins, treatment plan, side effects, reminders), which distinguishes it from siblings like get_my_account and get_lab_results. It never states a clean verb+resource summary sentence, but the resource and scope are unambiguous from the enumeration.

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 states a prerequisite ('Requires signing in with a Deer account') and hints at downstream use by noting the profile id is 'needed to log anything', which implies this is the lookup step before log_weight or report_side_effect. However, it never explicitly says when to call this versus get_my_account or get_lab_results, leaving routing to inference.

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

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint=false, so the safety profile is covered. The description adds real value beyond that by disclosing the content breadth of the response (all published product data in one call), which matters since there is no output schema; it doesn't mention auth, rate limits, or behavior for unknown product_id, 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?

Two tight sentences, front-loaded with the scope of returned data followed by the parameter's origin. The long enumeration is dense but every item maps to a distinct section of the response, so little is wasted; slightly list-heavy but not padded.

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 must convey what comes back, and it does so by listing the returned sections plus the input's provenance. Annotations cover the safety/idempotency profile, so the remaining omission is mostly edge-case behavior (unknown ID, unpublished products) rather than core call information.

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

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

Schema coverage is 0% for the single required parameter, so the description carries the burden and does: it names the source (search_products) and gives a concrete example value ('retatrutide'), establishing the ID format. It doesn't state error behavior or whether the slug/name is accepted, leaving a small 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 ('Everything Deer Supply publishes about one product') and then enumerates the payload: identity, sizes/prices, dosing schedule, box contents, COA reports, FAQ. It also names the sibling that produces the required input (search_products), so the agent can distinguish it from search_products without opening either 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?

The sentence 'product_id comes from search_products' gives clear ordering guidance: search first, then fetch detail for a chosen item. It stops short of explicit exclusions (e.g. don't call this for browsing many products, or for cart/pricing via quote_cart), so it is clear context rather than a full when/when-not map.

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 scope detail — notably that payment methods reflect what is accepted 'right now' — but says nothing about freshness, caching, or the static nature of the content.

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

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

A single front-loaded sentence that names the subject and then lists the covered topics. Every clause maps to a distinct piece of content an agent might ask for, 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 zero-parameter, read-only info tool with no output schema, the content enumeration is sufficient for an agent to decide whether to call it. The only gap is the lack of explicit routing against overlapping siblings such as get_help.

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 per the baseline there is nothing for the description to disambiguate. No parameter guidance is needed or missing.

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

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

The description names a specific resource (Deer Supply store information) and enumerates exactly what it returns: products, shipping destinations, payment methods, shipping costs, refund policy, lab testing, and contact route. That enumeration effectively separates it from siblings like get_product or get_trust_report, though no sibling is named explicitly.

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

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

Usage is only implied — an agent can infer this is for general 'about the store / how buying works' questions. There is no explicit statement of when to prefer this over get_help, get_trust_report, or delivery_estimate, and no exclusions, which leaves routing ambiguity for overlapping topics like contact and policy.

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

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

Annotations already declare readOnlyHint, idempotentHint, non-destructive, and closed-world, so the safety profile is covered. The description adds meaningful behavioral context beyond that: data is aggregated and de-identified, groups under 10 people are withheld, and each figure states its sample size and method.

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

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

Front-loaded with the core purpose, then a dense but purposeful enumeration of report contents. It is a single long sentence rather than a run-on, and every clause (sample size, suppression rule, de-identification) carries information.

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

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

With no output schema or parameters, the description carries the return-value burden and does so thoroughly, listing the report's sections and stating that each figure includes sample size and method. It is complete enough for an agent to know what comes back; only the response's exact shape remains unspecified.

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

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

The tool takes zero parameters, so there are no parameter semantics to document; the baseline for a no-arg tool is 4. The description correctly implies a single, unscoped output with no filtering options.

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 resource and enumerates exactly what the report contains (shipped/delivered orders, transit times, refunds, weight change, lab reports, reviews) with the source ('from its own records'). It is clearly distinct from sibling tools like get_lab_results or list_my_orders, though it never explicitly contrasts itself with 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?

The description explains what the report contains but gives no guidance on when an agent should call it versus alternatives (e.g., get_store_info or get_product for business credibility questions). No prerequisites, triggers, or exclusions are mentioned.

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 say it is a non-read-only, non-destructive, non-idempotent write; the description adds the auth prerequisite, the dedup behavior ('days already logged are skipped'), and a required human confirmation step — genuinely useful context beyond the hints. It still does not say what happens to partially invalid entries or what a failed import returns.

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 short sentences, each carrying a distinct load, with the auth prerequisite front-loaded before the operational detail. No filler or restatement of the tool name.

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

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

Covers the mutation's key prerequisites and confirmation flow, which is the most important gap for a write tool. However, with a nested entries array, a unit parameter, and no output schema, the description leaves the per-entry input format and error/partial-failure behavior 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 only 33%, but the description compensates partially by implying entries are dated weigh-ins ('days already logged are skipped') and listing plausible sources (scale app, spreadsheet, photo). It gives no guidance on the unit enum, the lb default, or the 500-entry cap beyond what the schema already 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 a concrete verb and resource: 'Add many past weigh-ins at once', with the bulk nature distinguishing it from the single-entry sibling log_weight. It never names that sibling explicitly, so differentiation is implied rather than stated.

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 real operating context: a Deer account sign-in is required, and the agent is told to show the list and get the person's OK before committing. It does not name log_weight as the alternative for a single weigh-in, nor state when import is inappropriate.

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

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint=false, so the safety profile is covered. The description adds value beyond that by disclosing the auth requirement and the sort order ('newest first'), which the agent cannot infer from schema or annotations. It does not describe pagination or truncation behavior.

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

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

Two tight sentences: the access prerequisite is front-loaded, then the payload contents. Every clause carries information, and there is no restating of the title or annotations.

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 field list ('number, date, status, total, items, tracking number and expected arrival') is exactly the return-value detail an agent needs, and the auth prerequisite is stated. The only meaningful gap is the undocumented limit/pagination behavior for a tool that could return many orders.

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

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

There is one parameter (limit) with 0% schema description coverage and no mention in the description. The min/max/default constraints live in the raw schema, but neither source explains what limit controls (page size vs. total results) or what happens when it is omitted, so the description fails to compensate for the coverage 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?

The description specifies the resource precisely — the signed-in customer's orders — and enumerates the returned fields (number, date, status, total, items, tracking number, expected arrival), which clearly separates it from a generic order lookup. It stops short of an explicit verb ('list') and does not name the sibling it overlaps with, such as track_order, but the scope 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?

It states a real prerequisite ('Requires signing in with a Deer account'), which tells the agent when the call can succeed. However, it gives no guidance on when to prefer this over track_order or get_my_account, and no note on how the limit/result-size affects usage.

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 a non-read-only, non-idempotent, non-destructive write. The description adds two pieces of context annotations do not carry: an authentication requirement and a confirmation-before-writing norm. It stops short of warning that repeat calls likely create duplicate entries given idempotentHint=false.

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

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

Three short, front-loaded sentences with no wasted wording; the precondition leads and the action follows. It is efficient and easy to scan, though the terse phrasing is more clipped than polished.

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 write tool with no output schema and half-documented parameters, it covers auth, target resource, and a confirmation step. What is missing is the consequence of repeated invocation and the shape of a successful result, which an agent calling a non-idempotent logging tool 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?

Schema coverage is only 50%; date and profile_id are documented inline (including "From get_my_health"), while weight and unit are not. The description obliquely references "the number" (weight) and "one of the customer's health profiles" (profile_id), adding marginal meaning beyond the schema but not compensating for the coverage 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 ("Record a weigh-in") scoped to the customer's health profiles. It is clear on its own, but it never distinguishes itself from the closely related sibling import_weights, so an agent must infer the single-entry vs bulk distinction.

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?

"Requires signing in with a Deer account" and "Confirm the number with the person first" give a prerequisite and a caution, which is real context. However, there is no guidance on when to pick this over import_weights or how it pairs with get_my_health, so 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 readOnly/idempotent/non-destructive, and the description reinforces this with 'Nothing is reserved or ordered.' It also discloses behavioral detail annotations cannot carry: sale and quantity-break pricing rules, CAD currency, and conditional delivery-estimate computation. Missing only failure modes (bad coupon, invalid postal code, unavailable variant).

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 purpose and then the practical constraints; every clause carries information. Slightly dense and could be split for scannability, but there is no redundant 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?

No output schema exists, so the description carries the return-value burden and does so by naming the priced components and conditional delivery estimate. It leaves error/edge-case behavior (invalid coupon, postal code outside Canada, unavailable variants) unspecified.

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

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

With only 33% schema coverage, the description compensates well: it explains that variant_id values originate from search_products, that coupon_code is optional, and that postal_code drives the delivery estimate (the one field already documented in schema). It does not explain qty limits (1-20 per item, 20 items max), which remain schema-only.

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 ('Price a cart') and enumerates the outputs (line prices with sale/quantity breaks, coupon, shipping, CAD total, delivery estimate), which separates it cleanly from siblings like create_cart_link and delivery_estimate. The scope note 'exactly as Deer Supply's checkout would' pins the semantics.

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 clear usage context: postal_code triggers a delivery estimate, variant_id must come from search_products, and 'Nothing is reserved or ordered' tells the agent this is a read-only quote rather than a purchase step. It does not explicitly name a when-not alternative (e.g., create_cart_link), 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 cover the safety profile (readOnlyHint=false, destructiveHint=false, non-idempotent). The description adds genuinely new context: an authentication prerequisite ('Requires signing in with a Deer account') and the emergency-escalation caveat. It still doesn't say whether duplicate reports are possible or what happens after submission, but it goes beyond the structured fields.

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 compact sentences, each earning its place: auth prerequisite, action, and safety exclusion. Front-loading the sign-in requirement is slightly awkward but not wasteful.

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?

There is no output schema and no indication of what the agent gets back or what happens to the report after submission (confirmation, care-team follow-up, status). For a write action tied to a health workflow, that leaves an agent unable to tell the user what to expect next.

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 50%: profile_id and started_on carry format hints, but severity's mild/moderate/severe enum is unexplained and the free-text description field (2000 char cap) has no guidance on what to include. The description's mention of 'severe' hints at severity semantics but does not define the three levels or what makes a report actionable.

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: 'Send a side effect to the customer's care team on one profile.' It clearly differs from generic siblings like get_help or log_weight. It does not explicitly distinguish itself from the sibling resolve_side_effect, which is the nearest ambiguity risk.

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 real context on when to use it and a critical exclusion: 'this report is not an emergency channel,' with an instruction to direct severe cases to 911/emergency care. It never names the alternative resolve_side_effect or explains report-vs-resolve, so routing between the two is left to inference.

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

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

Annotations declare non-readOnly, non-idempotent, non-destructive, which the description does not contradict. The description adds real context the annotations lack: an authentication requirement and the fact that the action is effectively one-way from the agent's side ('reopening is the care team's job'). It omits what happens to the record/how the result is confirmed, keeping it short of 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?

Three short sentences, no filler, with the auth prerequisite front-loaded before the action. It is appropriately sized for a two-parameter mutation, though the trailing 'reopening' clause could be folded in more tightly.

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 still covers auth, the ID sources, and the boundary of the action. What remains unspecified is the return/confirmation behavior after resolving, which is a minor gap for a simple state-change 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 50% (profile_id documented in schema as coming from get_my_health; side_effect_id undocumented there). The description supplies the missing provenance for side_effect_id, which is genuinely additive, but gives no format, validity, or closure-state constraints beyond that — baseline 3 for a half-covered 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?

States a specific verb and resource ('Mark one of the profile's open side effects as resolved') and scopes it to open side effects on a given profile. The clause 'Reopening one is the care team's job' implicitly separates it from report_side_effect and from any un-resolve action, so an agent can distinguish it without opening schemas.

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 clear preconditions (must be signed in with a Deer account) and the source of the identifier (side_effect_id from get_my_health), plus a negative case: reopening is not this tool's job. It does not name the sibling report_side_effect as the alternative for a different use case, so it stops short of a full when/when-not 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 cover the read-only, idempotent, closed-world safety profile, yet the description still adds real behavioral context: geographic scope (Canada), what a result contains (sizes, today's CAD price with sales applied, price per mg, quantity breaks, stock, links). It does not discuss pagination or result-count limits, but that is a minor gap given annotation coverage.

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 sentences, front-loaded with what is searched, then what is returned, then the no-argument behavior. The commercial framing ('Deer Supply's') is minimal and every sentence carries operational information.

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

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

For a two-parameter, no-output-schema search tool whose annotations carry the safety profile, the description supplies everything needed: catalog scope, return fields, and default no-argument behavior. Nothing an agent needs to invoke it correctly is missing.

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

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

Schema coverage is 50%: query has examples in the schema, but the category enum is undocumented there. The description compensates by naming the catalog segments (weight loss, recovery, ancillary capsules) that map onto the enum values, and by clarifying that both parameters are optional via the no-argument listing case.

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

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

The description names a specific verb and resource ('Search Deer Supply's catalog') and enumerates the catalog scope (weight loss, recovery, ancillaries). It is clearly distinguishable from get_product or compare_weight_loss_medications in practice, but it never explicitly contrasts itself with 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?

It gives one concrete usage rule — 'Call with no arguments to list everything' — which tells the agent how to enumerate. However, it offers no guidance on when to prefer this over get_product (single-item lookup) or compare_weight_loss_medications, leaving tool selection largely 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 declare this is a non-readOnly, non-destructive, non-idempotent mutation, and the description adds a genuine behavioral detail beyond them: the Deer account authentication requirement. It does not describe side effects or return behavior, but the auth note is meaningful added value over 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 with no waste: the prerequisite is front-loaded and the operational effect is stated immediately. 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 small 3-parameter mutation tool with no output schema, the description covers purpose, auth prerequisite, and the email categories it toggles, which is nearly sufficient. Minor gaps remain around defaults when a flag is omitted, but nothing critical to correct invocation 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 only 33% (only profile_id documented), so the description carries added burden. It loosely maps the two undocumented booleans to their meaning ('weigh-in reminder emails', 'reorder alert emails') and the 'and/or' signals they are independently optional, but this mostly restates the parameter names rather than adding new semantics.

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

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

The description states a concrete action ('Turn ... on or off') and names the specific resources affected: weigh-in reminder emails and reorder alert emails. This is clear and lets an agent understand the effect without opening the schema, though it does not explicitly differentiate itself from any sibling (none of which overlap in function).

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 states a prerequisite ('Requires signing in with a Deer account'), which is useful context, but gives no explicit when-to-use/when-not guidance or comparison to alternatives. Usage is only implied by the purpose itself.

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 and closed-world behavior, so the safety profile is covered. The description adds genuinely non-derivable disclosure: the email must match the one used at purchase, and it never returns addresses or payment details — a meaningful privacy boundary. It stops short of describing error behavior for failed verification.

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 scope-and-credential requirement, followed by return contents and the privacy exclusion. The parenthetical external-URL analogy is slightly expendable but harmless and short.

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?

No output schema exists, and the description compensates by naming what comes back (status, dates, items, tracking number) and what does not (addresses, payment details). For a two-param read-only lookup with full annotation coverage, this is nearly sufficient; only failure/not-found behavior is unaddressed.

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

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

Schema description coverage is 0%, so the description carries the burden, and it does explain that 'email' means the address the order was placed with, not an arbitrary contact. 'order_number' is left as the obvious order identifier, but the pairing semantics (both must match) are stated.

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 (order status lookup) and the exact key it requires: order number plus the email used at checkout. This clearly separates it from the sibling list_my_orders, which enumerates orders rather than resolving one. An agent can pick between them without opening either 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?

Usage is implied by the required credential pair and the reference to 'the same check as deer.supply/track', so an agent knows this is the single-order lookup. However, there is no explicit routing advice such as when to prefer list_my_orders or get_help, and no statement of what to do when the email does not match.

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