Human-operated physical world in the EU: make, assemble, measure, verify, ship.
Scored across 3 tools
Each tool targets a distinct purpose: get_status retrieves quote status, list_services provides service catalog, and request_quote initiates a quote request. There is no overlap or ambiguity, and the descriptions clearly delineate their roles.
All tool names follow a consistent verb_noun pattern with snake_case: get_status, list_services, request_quote. This is uniform and predictable, making it easy to infer tool behavior from the name.
With 3 tools, the set is concise and well-scoped for a niche service of requesting physical-task quotes. Each tool serves a necessary step (browse services, request quote, check status) and none feels redundant or missing for the core flow.
The tools cover the initial stages (listing, requesting, status-checking) but lack an explicit way to accept or reject a quote, which is a critical step in the workflow. The quote is delivered via email, but agents cannot act on it programmatically, leaving a significant gap in the lifecycle.
Status of a quote request made with request_quote. Needs the quote_id and the access_token returned by that call; there is no other way in, and the record is kept for 90 days. The quote itself is sent by e-mail.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | The quote_id returned by request_quote. | |
| access_token | Yes | The access_token returned by request_quote. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, covering safety. The description adds useful behavioral context: the record is retained for 90 days, access requires a token, and the quote itself is delivered via email. These details go beyond the structured hints and clarify access and data lifecycle, without contradicting any annotation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with purpose, and every clause earns its place. It efficiently conveys purpose, prerequisites, retention, and email behavior without extraneous detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has no output schema, so the description should explain what is returned. It says 'Status of a quote request' but does not specify the format or possible status values, nor whether the response includes any additional fields. The email note implies the quote is not returned, but the exact response structure remains unspecified. Given the simplicity (2 params, no nesting), this is a noticeable gap but not critical.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% and both parameters are well described. The description restates that these are returned by request_quote, which matches the schema but adds no new semantic meaning beyond the schema. Baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific purpose: 'Status of a quote request' and clearly identifies the resource (quote request). It also distinguishes itself from siblings by tying to request_quote and mentioning the required credentials, making it evident this tool reads status rather than listing services or creating quotes.
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 clearly implies the tool is used after request_quote, stating it needs the quote_id and access_token returned by that call, and that 'there is no other way in'. This gives clear context and prerequisites, though it doesn't explicitly name alternatives or exclusion conditions. The note that the quote is sent by email further clarifies what this tool does not do.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
What this company will and will not do in the physical world, the refused categories, example prices, the payment rules and the key contract terms. Identical to https://handsforagents.com/services.json. No authentication.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and idempotentHint, so the description is not responsible for establishing safety. It adds useful context beyond annotations: the exact upstream source URL and the explicit 'No authentication' requirement. It also clarifies that the data represents stated company policy, not just a generic service list.
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, information-dense sentence that front-loads the core content categories, then adds the exact data source URL and authentication requirement. Every clause earns its place; there is no filler or redundancy with the schema.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter, read-only reference tool, this is nearly complete: it states content, source, and authentication. It does not describe the response format or whether the data is live, but the '.json' URL strongly implies a JSON response, and the annotation set covers side effects and idempotency.
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 are zero parameters, so the baseline is 4. The description appropriately adds no parameter explanations because none are needed. The 'No authentication' note also confirms no hidden inputs are required.
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 title clearly names the resource ('services, prices and terms') and the description expands on the exact content: company scope, refused categories, example prices, payment rules, and contract terms. It is distinguishable from the sibling tools 'get_status' and 'request_quote', though it does not explicitly use a performing verb like 'returns a list of'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies a clear use case: retrieve company service policies and pricing information. It provides no explicit 'when to use vs alternatives' statement, but the content detail makes it evident that this is the reference tool for services/terms, while the siblings are status and quote actions. The sibling names help differentiate without further explanation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Send a physical-world task to a human in the Czech Republic for screening and a fixed-price quote. Not an order and not binding: nothing is charged and nothing is made until you accept the quote. A human answers by e-mail within 24 hours. Returns quote_id, access_token, response_due_at and nda_url. Store the access_token — it is the only way to read the quote back. No authentication.
| Name | Required | Description | Default |
|---|---|---|---|
| task | Yes | ||
| agent | No | ||
| client | Yes | ||
| allow_anonymised_example | No | Consent to publish this task as an anonymised example (no names, addresses or personal data), under the confidentiality section of the terms of service. Default false; can be withdrawn. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds substantial behavior beyond annotations: non-binding quote request, human response within 24 hours, returned fields, the access_token requirement, and 'No authentication.' This meaningfully clarifies the mutation semantics without contradicting readOnlyHint=false or destructiveHint=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?
The description is dense but efficient: it front-loads the core function and then covers binding status, response time, return values, access token handling, and authentication in four sentences. Every sentence contributes useful information 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?
Given the nested schema and absence of an output schema, the description reasonably covers the full quote workflow: what happens, when the quote arrives, what fields are returned, and how to access the quote later. Minor gaps like the exact email destination for file attachments remain, but the overall context is sufficiently complete.
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 25%, so the description must compensate for the four top-level parameters. It does not: task, client, agent, and allow_anonymised_example are not explained at the top level. The mention of 'physical-world task' hints at task, but no meaningful semantic guidance is added for the actual parameters.
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 clear verb and resource: 'Send a physical-world task to a human... for screening and a fixed-price quote.' It distinguishes itself from siblings by emphasizing the human-screening/quote-request nature, which is clearly different from get_status and list_services.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives clear context for when to call this tool: when a non-binding fixed-price quote is needed before any work or payment. The phrase 'Not an order and not binding... nothing is charged and nothing is made until you accept the quote' functions as a useful when-not/exclusion. It does not explicitly name alternative tools for ordering, but the context is clear enough.
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_statuslist_servicesrequest_quote688 humanoid robot component entities with 4-dimension compatibility checking. Vendor-neutral.
Physical-world evidence and operability checks with provenance and explicit data gaps.
EuEarth: agent-first commons — one free open model per domain on a stable keel; best wins.
Open manufacturing and maker facility locations for country and facility-type queries.
Add one secure layer between your agents and this server.