Caspar Manufaktur Materialberater

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

Annotations already declare the write/safety profile (readOnlyHint=false, destructiveHint=false, openWorldHint=false), and the description adds genuinely new context: the operation is idempotent/retry-safe and no personal data is transmitted. It stops short of stating auth requirements or what the created record looks like, but it goes beyond the annotations.

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

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

A single front-loaded sentence with the verb first, no filler or repetition. It is appropriately sized for a two-parameter tool, though the dense noun string ("Caspar handoff record for a project enquiry, sample request or Wallcheck") takes a read or two to parse.

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

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

For a simple two-param mutation with no output schema and annotations covering safety, the description covers what is created and the retry/no-PII traits. It omits any relationship to start_project_handoff and what the caller receives back, leaving a real ambiguity an agent must resolve before invoking.

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%: the idempotency_key is well documented in the schema itself. The description compensates for the undocumented next_step by spelling out its three valid values (project enquiry, sample request, Wallcheck) in prose, which helps map intent to enum. Baseline 3 is appropriate since the schema already carries the key parameter's 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?

States a specific verb and resource (Create a ... Caspar handoff record) and enumerates the three supported request types, so the agent knows exactly what gets written. It does not, however, differentiate itself from the sibling start_project_handoff, leaving the agent to guess which handoff tool applies.

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?

"Safely retryable" and "without submitting personal data" imply the usage context (retry-safe writes for non-PII enquiries), but there is no explicit when-to-use-this-vs-alternative guidance. With a sibling literally named start_project_handoff, this is a meaningful gap.

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, destructiveHint=false and openWorldHint=false, so the safety profile is fully covered structurally. The description adds the word "verified," implying the returned data is authoritative rather than raw, which is a small but real extra signal. It does not describe the shape of the returned directory, but with annotations carrying the behavioral burden 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?

One front-loaded sentence with no filler; the resource being fetched is the first thing after the verb. Nothing to trim and nothing buried.

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-argument, read-only, closed-world lookup with no output schema, the description tells an agent what it will receive at a summary level. A brief indication of what the company record contains (or that it covers a single fixed entity) would make it fully self-contained, but the gap is minor.

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. Nothing in the description misrepresents the input surface, and there is no argument syntax to explain.

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") and enumerates the resources returned (company, contact, handoff information) scoped to a named entity (Caspar Manufaktur). It is clear what the tool fetches, though it makes no explicit effort to distinguish itself from the handoff-oriented siblings like start_project_handoff or create_idempotent_project_handoff, which the word "handoff" arguably overlaps with.

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

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

There is no guidance on when to call this versus the sibling tools, nor any stated prerequisites. An agent must infer usage entirely from the purpose statement, and the mention of "handoff information" could steer it toward the handoff tools by mistake.

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, destructiveHint=false and openWorldHint=false, so the safety profile is fully covered by structured data. The description adds useful content-level context (the returned attributes) but says nothing about pagination, ordering, or whether the list is static — reasonable but not rich given the low annotation bar.

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 efficient sentence with the core action front-loaded and no wasted clauses. The word 'selected' adds ambiguity rather than information, slightly weakening an otherwise tight statement.

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 pragmatically compensates by naming the returned fields. What remains missing is clarification of what 'selected' means and whether results are scoped or paginated, but for a simple read-only listing the definition is close to sufficient.

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

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

The tool takes zero parameters, so per the baseline there is no parameter semantics to document. The schema is empty and consistent with the description, which correctly implies an unfiltered list operation.

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 ('List ... wallpaper materials') and even names the attributes returned (surface, width, primary use cases). It does not explicitly distinguish itself from the sibling recommend_material, and the qualifier 'selected' is undefined given there are no input parameters, leaving ambiguity about whether this is a fixed catalog.

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

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

There is no when-to-use guidance, no prerequisites, and no mention of when an agent should prefer this over recommend_material. Usage is only inferable from the verb 'List'.

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

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

Annotations already declare a safe read-only, closed-world, non-destructive operation, so the safety profile is covered without description help. The description adds nothing beyond that baseline — no note on whether it returns one or many materials, whether it is deterministic, or what the recommendation is based on.

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 clean, front-loaded sentence with no wasted words. It is efficient, but the brevity is also under-specification rather than disciplined concision.

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 one-parameter recommendation tool with no output schema, the description should at minimum explain what a priority means and roughly what comes back. Neither is present, leaving the agent to guess at both input semantics and return shape.

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 burden, and it only names the parameter as 'project priority'. The five German enum values (brandschutz, robust, effekt, nachhaltig, feuchtraum) are left entirely unexplained, so an agent cannot tell what each priority means.

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 ('Recommend') and resource ('Caspar material') plus the selecting input ('project priority'). It is distinguishable from list_materials (listing vs. recommending), though it does not explicitly differentiate itself in text.

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

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

No guidance on when to use this versus list_materials or the other siblings, and no prerequisites or exclusions stated. The only implied cue is the word 'Recommend' in the name.

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, destructiveHint=false and openWorldHint=false, so safety is covered structurally. The description adds a genuinely useful behavioral fact beyond them — 'does not submit personal data' — which reassures around privacy for an enquiry-routing call. It does not say where the URL leads or whether it expires, 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?

Two short sentences, front-loaded with the return value and followed by the privacy constraint. Every clause carries information; nothing is padding.

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 single-parameter tool with no output schema and safety annotations already present, the description covers what is produced (a URL), the supported scenarios, and the privacy boundary. It leaves out what Caspar is and the URL's lifespan, which are minor for a routing 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 0%, so the schema supplies only bare enum tokens. The description compensates by mapping each to a human scenario, notably explaining 'wallcheck' as a print-file check, which an agent could not derive from the token alone. With only one self-describing enum parameter, this is sufficient.

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 gives a concrete verb (return) and resource (a Caspar URL) and enumerates the three supported scenarios, which map onto the enum values. It is clear on its own, but it does not distinguish itself from the sibling create_idempotent_project_handoff, which sounds functionally adjacent.

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 rather than stated: the three listed scenarios (project enquiry, sample request, print-file check) correspond to the enum values, so an agent can infer when to call it. However, no condition selects this tool over create_idempotent_project_handoff, and no exclusions are given.

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