Material information and recommendations for custom digital-print wallpaper B2B projects.
Scored across 5 tools
create_idempotent_project_handoff and start_project_handoff both target project handoffs and are likely to be confused, though their descriptions do distinguish record creation from URL generation. list_materials and recommend_material are clearly distinct, but get_company_information also mentions handoff information, adding mild overlap.
All tools use snake_case with a leading verb (create_, get_, list_, recommend_, start_), which is consistent. The adjective 'idempotent' in create_idempotent_project_handoff is an implementation detail that makes the name unnecessarily long but does not break the verb_noun pattern.
Five tools are well-scoped for a material advisory server covering listing, recommending, company lookup, and project handoff. Each tool has a clear place and there is no redundant filler.
The surface covers material listing, recommending, company info, and handoff initiation, but lacks a get_material_details tool and any way to retrieve or track a handoff record after creation. These gaps may force agents to work around missing read/lifecycle operations.
Create a safely retryable Caspar handoff record for a project enquiry, sample request or Wallcheck without submitting personal data.
| Name | Required | Description | Default |
|---|---|---|---|
| next_step | Yes | ||
| idempotency_key | Yes | Client-generated key of at least eight characters. Reuse only when retrying the same handoff. |
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.
Get verified company, contact and handoff information for Caspar Manufaktur.
| Name | Required | Description | Default |
|---|---|---|---|
| fields | No | Optional. Return only these fields; omit to get all fields. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false and a closed (non-open-world) data source, so the safety profile is covered structurally. The description adds one piece of context beyond them — the data is 'verified' — but says nothing about freshness, caching, or what happens when a requested field is absent.
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 no filler; the verb and resource come first. It is efficient, though it spends no words on the one place guidance would help most (when to call it).
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 read tool with full schema coverage and annotations that already carry the safety profile, this is close to sufficient; the output has no schema, but the description at least characterizes the returned content (company, contact, handoff). 'Handoff information' remains vague but is not blocking.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and the single 'fields' parameter is fully documented in-schema, including its enum and the omit-for-all behavior. The description adds no meaning beyond that, so the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb ('Get') and a specific resource set ('company, contact and handoff information') scoped to a named company, which is clearly distinct from the material- and handoff-mutation siblings. It stops short of explicitly differentiating itself from start_project_handoff, but the resource named 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?
There is no when-to-use guidance, no prerequisites, and no mention of alternatives among the sibling tools. The agent must infer that this is the reference-data call to make before project handoff work, with nothing in the text supporting that inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List selected wallpaper materials with surface, width and primary use cases.
| Name | Required | Description | Default |
|---|---|---|---|
| id | No | Optional. Return only the material with this id. | |
| limit | No | Optional. Page size, default 50. | |
| offset | No | Optional. Number of materials to skip, default 0. | |
| priority | No | Optional. Filter by priority tag, e.g. brandschutz, robust, effekt, nachhaltig, feuchtraum. |
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 and scope profile is clear. The description adds that the tool returns surface, width, and use cases, which is useful behavioral context. It doesn't mention pagination behavior beyond the schema, but annotations carry most of the burden.
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 front-loads the verb and resource with no waste. It is appropriately sized for a simple list tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool is a simple read-only list with full schema coverage and no output schema, the description is minimally sufficient. However, it omits pagination behavior (offset/limit interplay) and the relationship to recommend_material, which would make it more complete for an agent choosing between them.
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 all four parameters (id, limit, offset, priority) are fully documented in the schema. The description adds no parameter-specific meaning beyond what the schema provides, so the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a clear verb (List) and resource (wallpaper materials) and hints at the returned fields (surface, width, primary use cases). It does not explicitly differentiate from the sibling recommend_material, but 'List' vs 'recommend' gives a reasonable 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?
No indication of when to use this tool versus recommend_material, which is the natural alternative for material selection. The sibling names are not referenced, and no context is given about when to call it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recommend a Caspar material based on a project priority.
| Name | Required | Description | Default |
|---|---|---|---|
| priority | Yes |
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.
Return a Caspar URL for a project enquiry, material sample request or print-file check. The tool does not submit personal data.
| Name | Required | Description | Default |
|---|---|---|---|
| next_step | Yes |
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.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
get_company_information1 field changedInput schema / properties / fieldsAdded value: +{
+ "description": "Optional. Return only these fields; omit to get all fields.",
+ "items": {
+ "enum": [
+ "name",
+ "description",
+ "website",
+ "contact_url",
+ "wallcheck_url",
+ "materials_url",
+ "developers_url"
+ ],
+ "type": "string"
+ },
+ "type": "array"
+}list_materials4 fields changedInput schema / properties / idAdded value: +{
+ "description": "Optional. Return only the material with this id.",
+ "type": "string"
+}Input schema / properties / limitAdded value: +{
+ "description": "Optional. Page size, default 50.",
+ "maximum": 50,
+ "minimum": 1,
+ "type": "integer"
+}Input schema / properties / offsetAdded value: +{
+ "description": "Optional. Number of materials to skip, default 0.",
+ "minimum": 0,
+ "type": "integer"
+}Input schema / properties / priorityAdded value: +{
+ "description": "Optional. Filter by priority tag, e.g. brandschutz, robust, effekt, nachhaltig, feuchtraum.",
+ "type": "string"
+}create_idempotent_project_handoffget_company_informationlist_materialsrecommend_materialstart_project_handoffAgent-ready print shop in Sao Paulo: catalog, official BRL quotes per m2, shipping, PIX orders.
Hidden (flush) doors and glass partitions: price, specs and 3D models (GLB, IFC, DXF) on demand.
Metadata B2B ad reports, audience planning, brand creative, and campaign readiness.
Print existing artwork on custom wall art, apparel, and gifts.
Add one secure layer between your agents and this server.