Dolphin Centrifuge

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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive, closed-world), so the description's added value is the content scope: the 'Dated' qualifier warns the list may be stale, the inventory state (in stock vs. built to order) is disclosed, and the exclusion of prices/serial numbers prevents wasted follow-up calls. Return format/timing is still unspecified.

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 listing vendor, location, and returned fields with zero filler. The word 'Dated' is slightly ambiguous (data freshness vs. dates) but the sentence is otherwise tight.

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 usefully enumerates what comes back (model, type, condition, availability) and what does not (prices, serial numbers), plus the vendor/location scope. It could clarify that the sole parameter filters this same list, but nothing essential for a correct call 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?

With 100% schema description coverage and one optional, self-documenting filter, the schema carries the parameter guidance. The description adds no filter syntax or behavior of its own, so the baseline 3 applies.

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

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

States a specific resource (Alfa Laval centrifuges in stock at Dolphin Centrifuge, Warren MI) and enumerates the returned fields (model, type, condition, stock vs. built-to-order), which an agent can use to tell it apart from get_centrifuge_specs or list_centrifuge_models. It does not, however, explicitly name or contrast 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?

Usage is only implied via the resource ('in stock at Dolphin') and the negative scope ('no prices or serial numbers'), which steers an agent away from a pricing query but does not say when to prefer this over list_centrifuge_models or request_quote. No explicit when-not conditions or named alternatives.

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

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

Annotations already cover safety (readOnly, idempotent, non-destructive, closed-world), so the description earns credit by adding output semantics: capacities are always reported with their fluid and conditions, which prevents misreading the returned numbers. With no output schema, this return-value characterization is genuinely additive.

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

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

Three tight sentences, front-loaded with what is returned, then usage, then an output caveat. Nothing is redundant or 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?

For a read-only, annotation-covered lookup with two optional params, the definition is nearly complete: it names the domain, the accepted identifiers, and the shape of the capacity data. A brief note on no-match behavior or result format would close the remaining 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 100%, so both parameters are already documented with examples, and the description largely restates the same model/query examples. Baseline 3 is appropriate; it adds no format, matching, or fallback 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?

States a clear verb+resource: published specifications for Alfa Laval disc-stack/decanter centrifuges or Dolphin modules remanufactured by Dolphin Centrifuge. This implicitly distinguishes it from list_centrifuge_models and size_centrifuge, 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?

Gives a how-to-call hint (pass an exact model, or a free-text query when the model is unknown), which is useful routing between the two parameters. However it never states when to prefer this tool over siblings like list_centrifuge_models or size_centrifuge, or what to do on a no-match.

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 one genuinely new behavioral detail — the output is 'one line each' — which matters because there is no output schema, but it says nothing about ordering, result limits, or what happens when a filter matches nothing.

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

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

A single sentence that front-loads the action and resource and then appends the optional filters. No filler, no redundancy.

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

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

For a zero-required-parameter, two-filter list tool with annotations covering safety, the description plus schema is nearly sufficient; the 'one line each' hint compensates for the absent output schema. Minor gaps remain around result count and ordering.

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%, with the enum values for 'type' and examples for 'application' already documented in the schema. The description restates the same semantics ('type' and 'application/fluid keyword') without adding format or matching behavior, so baseline 3 applies.

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

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

States a specific verb and resource ('List the centrifuge models Dolphin publishes specs for') plus the scope of what is returned ('one line each'). It does not, however, explicitly distinguish itself from the sibling get_centrifuge_specs, so an agent must infer that this is the catalogue-level listing rather than the detail lookup.

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 phrase 'optionally filtered by type and by application/fluid keyword' implies when the filters are useful, but there is no explicit when-to-use guidance and no routing to alternatives such as get_centrifuge_specs or size_centrifuge. Usage is implied rather than stated.

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

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

Annotations cover the safety profile (readOnlyHint=false, destructiveHint=false, openWorldHint=true, idempotentHint=false), and the description adds genuinely new context: it is an outbound communication on the user's behalf, requires real identity and consent, and is asynchronous ('replies by email or phone within a few business days'). That is meaningful disclosure beyond structured fields, though nothing is said about failure modes or duplicate-submission 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?

Three short sentences, front-loaded with the action, followed by the consent precondition and the expected response channel. Every sentence carries information; nothing is redundant.

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 usefully explains the outcome (email or phone reply within a few business days), so the agent knows the call is fire-and-forget rather than returning data. The consent and identity requirements are the key missing-in-annotations facts and both are present. Minor gap: no mention of what a successful submission returns or whether repeat calls create duplicates.

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% for all 9 parameters, so the schema already documents name, email, model, phone, company, country, message, flow_gpm and application. The description only adds the soft requirement that name/company/email be the user's real details, which is marginal. Baseline 3 is correct.

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 ('send a quote or information request'), the resource (quote/request), and the recipient ('Dolphin Centrifuge sales on behalf of the user'). The sibling tools are all read-only lookups (stock, specs, models, sizing), so this is unambiguously the single outbound action tool.

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

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

Gives a strong precondition ('Only call with the user's explicit consent and their real name, company and email'), which tells the agent exactly when invocation is permissible. It does not name an alternative tool or explicitly say when not to use it, but the read-only sibling set makes the routing obvious.

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, so safety is covered. The description adds real behavioral context beyond that: a pure deterministic computation with a disclosed formula and an extra output ('basic separation guidance') not visible in the schema.

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

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

Two sentences: formula first, invocation rule second. No filler, and the key input rule is front-loaded enough to be read in one pass.

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

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

With no output schema, the description carries the return burden and does so by naming both the computed third value and the separation guidance. Missing only edge-case behavior (e.g. how it responds to zero or one inputs), which is minor for a formula 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 100% and unit semantics (cm, x g, meters) are in the schema, so baseline 3 applies. The description adds a genuine constraint the schema cannot express: exactly two of the three parameters must be supplied, since required is empty and additionalProperties is false.

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 (relative centrifugal force / g-force calculator) and even names the governing formula RCF = 1.118e-5 x r(cm) x RPM^2. This is clearly distinguishable from the sibling tools, which are inventory, spec lookup, listing, and quoting.

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 states the invocation rule: supply any two of bowl_diameter_m, rpm, g_force and receive the third plus guidance. That is clear context for how to call it, but it never names an alternative tool or a when-not-to-use-this condition.

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