A person in the Czech Republic (EU) makes, assembles, measures, verifies and ships physical things for your agent, with an evidence package for every task. A human screens and quotes each request; the operator gets an invoice from a registered EU company.
Scored across 5 tools
Each tool has a distinct role in the quote-to-delivery lifecycle: request_quote, create_task, get_status, confirm_delivery, and list_services. get_status combines status retrieval and messaging, but its boundaries against other tools remain clear.
All tool names follow a consistent snake_case verb_noun pattern: confirm_delivery, create_task, get_status, list_services, request_quote. There are no deviations in style or convention.
Five tools are well-scoped for the server's purpose, covering service information, quote requests, task creation, status tracking, and delivery confirmation. No tool appears redundant or out of place.
The tool surface covers the full lifecycle from requesting a quote through creating a task, monitoring status, and confirming or disputing delivery. Supporting operations like listing services and handling payment links are included, leaving no obvious dead ends.
Accepts or disputes the delivery of a task. accepted=true closes the task and, for a card hold, captures it. accepted=false with a reason opens a dispute, answered by a human within 2 business days; it is possible at the evidence stage, before the balance is paid, as well as after delivery. Without either, the task counts as accepted 7 days after delivery. Returns the task status.
| Name | Required | Description | Default |
|---|---|---|---|
| reason | No | Required when accepted is false: what differs from the quote. | |
| task_id | Yes | Id of the task, of the form t_... | |
| accepted | Yes | true accepts the delivery, false disputes it. | |
| access_token | Yes | Access token of the quote and its task, issued with the quote. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare destructive/non-idempotent/openWorld, so the safety profile is covered. The description adds valuable context beyond that: capture of a card hold, human review within 2 business days, dispute eligibility across stages, and the 7-day auto-accept fallback. It does not explicitly state that acceptance is irreversible, but 'closes the task' implies it.
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?
Dense but front-loaded: the decision branches come first, the default fallback and return value last. Multiple semicolon-joined clauses make it slightly run-on, but every clause 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?
For a mutation tool with no output schema, the description covers outcomes, the dispute lifecycle, and the timeout default, and notes it returns task status. Sufficient for correct invocation, though the error/auth expectations for an invalid access_token are unstated.
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%, so the baseline is 3. The description goes further by explaining the consequence of each accepted value and the conditional requirement of reason (dispute path), adding meaning beyond the schema's terse 'true accepts the delivery, false disputes it.'
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 ('Accepts or disputes the delivery of a task') and immediately names the two modes. It is readily distinguishable from siblings like create_task, get_status, and request_quote.
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?
Clearly states when to use each branch: accepted=true closes/captures, accepted=false with a reason opens a dispute, and the no-action default auto-accepts after 7 days. It also notes dispute timing relative to the evidence stage and payment. No sibling alternatives are named, but this tool has no true sibling alternative.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Accepts a quote and the terms of service (quote_id, access_token, terms_accepted=true, terms_version as stated in the quote) and creates the task. Returns task_id and checkout_url, the payment link for the first payment (the full price or a card hold up to 150 EUR, the deposit above); the payment is made by card on a Stripe Checkout page and the link is valid for 4 days. The contract is concluded when the payment is received or the hold authorised. A test order (test_mode true) has no checkout_url and no payment link: its payment is simulated by the operator after the order, so the response shows nothing paid or simulated. A repeated call for the same quote returns the same task.
| Name | Required | Description | Default |
|---|---|---|---|
| quote_id | Yes | Id of the quote, of the form q_... | |
| access_token | Yes | Access token of the quote and its task, issued with the quote. | |
| terms_version | Yes | Version of the terms being accepted, currently 2026-09-29. | |
| terms_accepted | Yes | Acceptance of https://handsforagents.com/terms.html by the operator. | |
| allow_anonymised_example | No | Optional. Consent to publish this task as an anonymised example (terms, section 10); true only when the client explicitly agreed. Default false. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only carry the safety/idempotency profile; the description adds substantial operational context: the payment is a card charge or a hold up to 150 EUR on Stripe Checkout, the link expires in 4 days, the contract is concluded on payment/authorisation, and test_mode orders have no checkout_url with simulated payment. This is well beyond what the annotations declare.
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 front-loaded with the action and the return values, and every sentence carries information (payment mechanics, test mode, idempotency). It is slightly dense, with nested parentheticals about the hold amount and deposit, but nothing 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 correctly explains what is returned (task_id, checkout_url) and how the response differs in test mode. Combined with the payment/contract lifecycle and idempotency notes, an agent has everything needed to invoke and interpret this 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%, so the baseline is 3, but the description adds meaning beyond the schema: terms_version must be the version stated in the quote (not merely the current one listed in the schema), terms_accepted must be true as an acceptance act by the operator, and quote_id/access_token pair identifies the same quote and task. That is real semantic value on top of the structured fields.
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+resource pair ('Accepts a quote and the terms of service ... and creates the task'), plus the exact return values (task_id, checkout_url). It is clearly distinguishable from siblings like request_quote (which issues the quote) and get_status.
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 a clear pre-condition for use (a quote plus terms_version as stated in the quote must exist and be accepted) and a repeat-call rule ('A repeated call for the same quote returns the same task'). It does not explicitly name alternatives or exclusions (e.g., when to prefer get_status instead), 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.
Returns the current status of a quote (id = quote_id) or a task (id = task_id): status, next_action (a short text on the next step), payments, updates, and messages with the operator (newest first, from operator or you). The answer is short: older_updates and older_messages count what is left out; full=true returns everything. With the optional message the call also stores a plain-text reply to the operator and e-mails it to the operator; message_sent is then true. While the operator has a message that has not been returned yet, the reply is not stored (message_sent: false) and the answer contains that message. The same text again within 10 minutes is ignored (duplicate_ignored: true). A status can change at any time; every call returns the state at that moment. test_mode true marks a test order: nothing is paid or invoiced.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | quote_id or task_id. | |
| full | No | true returns the complete answer. | |
| message | No | Optional reply to the operator: plain text, 1-2000 characters. Without it the call is a plain status check. | |
| access_token | Yes | Access token of the quote and its task, issued with the quote. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Adds substantial behavior beyond the annotations: the truncation/older_updates/older_messages semantics, full=true, the operator-message gate that defers storing a reply and flips message_sent, the 10-minute duplicate_ignored rule, and the volatility of status. It also implicitly explains why readOnlyHint=false and idempotentHint=false (the call can write and email a reply), so no contradiction.
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 dense but relevant clauses about return shape and edge cases; each sentence carries information. It is somewhat long and run-on, which slightly hurts readability, but 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 carries the full burden and does so: it enumerates the returned fields, the truncation behavior, and the message_sent/duplicate_ignored/test_mode flags. An agent has everything needed to call and interpret it.
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%, giving a baseline of 3, and the description adds real meaning: id may be either a quote_id or task_id, full=true returns everything (with the older_* counts otherwise), and message triggers storage plus e-mail with the duplicate/queue caveats.
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 ('Returns the current status of a quote or a task') and enumerates what is returned (status, next_action, payments, updates, messages). It clearly distinguishes the two modes (status check vs. answering the operator), though it does not explicitly name any of the sibling tools.
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 explains the conditional use of the optional message ('Without it the call is a plain status check'), which implies when each mode applies. However, it offers no explicit guidance on when to call this versus confirm_delivery, create_task, list_services, or request_quote.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Returns what the service does and does not do, the refused categories, prices and how to pay, as a short summary. No authentication. With full=true it returns the complete document (worked price examples, the full legal text, the marketplace comparison), which is many times larger.
| Name | Required | Description | Default |
|---|---|---|---|
| full | No | true returns the complete document (the same as /services.json); false (default) returns a short summary. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover read-only, idempotent and non-destructive behavior, so the description's extra value is the explicit 'No authentication' requirement and the warning that full=true returns a document 'many times larger', which is real cost/payload context. It also discloses what the summary omits (worked examples, legal text, marketplace comparison), which the annotations cannot 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 with no filler; the default summary behavior is front-loaded and the full=true expansion follows. The first sentence is somewhat inventory-like and dense, but every clause carries information an agent needs.
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, so the description must describe the return value, and it does so by enumerating the summary sections and the extra sections in full mode. Missing only the return format/serialization detail, which is minor for a read-only informational 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%, so the formal baseline is 3, but the description goes beyond the schema by naming the concrete contents unallocated by full=true and flagging the size differential. That reduces the risk of an agent accidentally requesting the full document when it only needs a summary.
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 (returns) and enumerates the resource content: what the service does/does not do, refused categories, prices, payment. That is far more informative than the name 'list_services' alone and clearly separates it from the transactional siblings (confirm_delivery, request_quote). It lacks any explicit contrast with a sibling, so it stops short of a 5.
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 the full=true versus default tradeoff, which is genuine usage guidance for the one parameter. However, it never says when an agent should reach for this tool versus get_status or request_quote, nor any preconditions. 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.
Creates a request for a fixed-price quote from a human. The request is not binding and nothing is charged. Required: description, email and name (the person or company on the invoice, normally the recipient or company in delivery_address). delivery_address is needed when a physical item is shipped, handed over or collected: one plain string with recipient, street, postcode and city, country; a phone number is optional. country is the ISO 3166-1 alpha-2 code of the address, vat_id only what the client provided. The fields are sent flat, as in the examples. Returns quote_id (of the form q_..., issued only in this response), access_token (shown once; the only key to the quote and its task), nda_url and upload_url (the address input files are POSTed to). A human answers within 24 hours, every day, with a quote or a refusal. No authentication. Shortest possible request: {"description":"Make 20 rubber gaskets, 60 mm outer diameter, black EPDM.","email":"ops@example.com","name":"Example Inc."}. With a delivery address and an input file: {"description":"Make 20 rubber gaskets, 60 mm outer diameter, black EPDM.","email":"ops@example.com","name":"Example Inc.","delivery_address":"Example GmbH, Musterstr. 1, 10115 Berlin, DE, +49 30 000000","input_files":["https://example.com/gasket-drawing.pdf"]}
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | Required. The person or company on the invoice, normally the recipient or company in delivery_address. | |
| Yes | Contact e-mail of the operator; the quote is sent here. | ||
| vat_id | No | VAT or tax id for the invoice, as given by the client. Optional. | |
| country | No | Operator's country, ISO 3166-1 alpha-2, upper case, normally that of the delivery address. Optional. | |
| currency | No | EUR or USD. Default EUR. | |
| deadline | No | Latest acceptable delivery date, ISO 8601. Optional. | |
| services | No | Service ids. Optional. | |
| agent_name | No | Name of the agent or platform. Optional. | |
| description | Yes | What is to be done, plainly: quantity, material, colour, size, tolerances, what counts as done. | |
| input_files | No | HTTPS URLs of input files (photos, sketch, STEP/STL model, PDF drawing). At most 20. | |
| deliverables | No | What the client expects to receive. Optional; otherwise part of description. | |
| delivery_address | No | Required for a physical shipment. One plain string: recipient, street, postcode and city, country, as given by the client; a phone number last is optional. | |
| allow_anonymised_example | No | Consent to publish this task as an anonymised example; true only when the client explicitly agreed. Default false. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare the safety profile (mutating, non-idempotent, open-world), and the description adds substantial behavior beyond that: no authentication, the request is non-binding with nothing charged, a human answers within 24 hours every day, and the access_token is 'shown once' as the only key to the quote. That is exactly the kind of context an agent cannot get from 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?
Front-loaded with the required fields and the non-binding guarantee, then semantics, then return values and the promised turnaround. It is dense and runs long, but nearly every sentence carries operational or parameter guidance; only slight trimming would help.
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 13-parameter mutation tool with no output schema, the description covers the return payload (quote_id, access_token, nda_url, upload_url), the response latency, and the auth model. An agent has everything needed to invoke it correctly and interpret the result.
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%, so the baseline is 3. The description adds real meaning on top: delivery_address is flattened into one plain string (recipient, street, postcode, city, country, optional phone last), country is ISO 3166-1 alpha-2, vat_id only what the client provided, and fields are sent flat. Two blind examples further pin the shape.
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 opens with a specific verb+resource ('Creates a request for a fixed-price quote from a human') and immediately scopes it with 'not binding and nothing is charged'. This distinguishes it from siblings like create_task and confirm_delivery, which an agent can tell apart without opening 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?
It states the required fields and gives a clear conditional rule for delivery_address ('needed when a physical item is shipped, handed over or collected') plus guidance for country and vat_id. It does not explicitly compare against sibling tools or state when NOT to use this tool, 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.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
confirm_delivery3 fields changedInput schema / properties / accepted / descriptionAdded value: +"true accepts the delivery, false disputes it."Input schema / properties / access_token / descriptionPrevious value: -"Token returned by request_quote."New value: +"Access token of the quote and its task, issued with the quote."Input schema / properties / task_id / descriptionAdded value: +"Id of the task, of the form t_..."create_task3 fields changedInput schema / properties / access_token / descriptionPrevious value: -"Token returned by request_quote."New value: +"Access token of the quote and its task, issued with the quote."Input schema / properties / allow_anonymised_example / descriptionPrevious value: -"Optional. Consent to publish this task as an anonymised example (terms, section 10). Only true if the client explicitly agreed. Default false."New value: +"Optional. Consent to publish this task as an anonymised example (terms, section 10); true only when the client explicitly agreed. Default false."Input schema / properties / quote_id / descriptionAdded value: +"Id of the quote, of the form q_..."get_status3 fields changedInput schema / properties / access_token / descriptionPrevious value: -"Token returned by request_quote."New value: +"Access token of the quote and its task, issued with the quote."Input schema / properties / full / descriptionPrevious value: -"true: the complete answer."New value: +"true returns the complete answer."Input schema / properties / message / descriptionPrevious value: -"Optional reply to the operator: plain text, 1-2000 characters. Leave it out for a plain status check."New value: +"Optional reply to the operator: plain text, 1-2000 characters. Without it the call is a plain status check."list_services1 field changedInput schema / properties / full / descriptionPrevious value: -"true for the complete document (same as /services.json); false (default) for a short summary."New value: +"true returns the complete document (the same as /services.json); false (default) returns a short summary."request_quote9 fields changedInput schema / properties / allow_anonymised_example / descriptionPrevious value: -"Consent to publish this task as an anonymised example. Only true if the client explicitly agreed. Default false."New value: +"Consent to publish this task as an anonymised example; true only when the client explicitly agreed. Default false."Input schema / properties / country / descriptionPrevious value: -"Operator's country, ISO 3166-1 alpha-2, upper case. Optional."New value: +"Operator's country, ISO 3166-1 alpha-2, upper case, normally that of the delivery address. Optional."Input schema / properties / deliverables / descriptionPrevious value: -"What you expect to receive. Optional; otherwise put it in description."New value: +"What the client expects to receive. Optional; otherwise part of description."Input schema / properties / delivery_address / descriptionPrevious value: -"Required for a physical shipment. One plain string: recipient, street, postcode and city, country (only what the user gave; never invent one); a phone number last is optional."New value: +"Required for a physical shipment. One plain string: recipient, street, postcode and city, country, as given by the client; a phone number last is optional."Input schema / properties / description / descriptionPrevious value: -"What is to be done, plainly: everything the user told you (quantity, material, colour, size, tolerances, what counts as done)."New value: +"What is to be done, plainly: quantity, material, colour, size, tolerances, what counts as done."Input schema / properties / email / descriptionPrevious value: -"Contact e-mail of the operator; the quote goes here."New value: +"Contact e-mail of the operator; the quote is sent here."Input schema / properties / name / descriptionPrevious value: -"Required. The name of the person or company for the invoice."New value: +"Required. The person or company on the invoice, normally the recipient or company in delivery_address."Input schema / properties / services / descriptionPrevious value: -"Service ids, if you know them."New value: +"Service ids. Optional."Input schema / properties / vat_id / descriptionPrevious value: -"VAT or tax id for the invoice, only if the user gave it; never guess. Optional."New value: +"VAT or tax id for the invoice, as given by the client. Optional."create_task1 field changedInput schema / properties / terms_version / descriptionPrevious value: -"Version of the terms being accepted, currently 2026-09-28.3."New value: +"Version of the terms being accepted, currently 2026-09-29."get_status1 field changedInput schema / properties / fullAdded value: +{
+ "default": false,
+ "description": "true: the complete answer.",
+ "type": "boolean"
+}request_quote2 fields changedInput schema / properties / delivery_address / descriptionPrevious value: -"Required for a physical shipment. One plain string: recipient, street, postcode and city, country; a phone number last is optional."New value: +"Required for a physical shipment. One plain string: recipient, street, postcode and city, country (only what the user gave; never invent one); a phone number last is optional."Input schema / properties / vat_id / descriptionPrevious value: -"VAT or tax id for the invoice. Optional."New value: +"VAT or tax id for the invoice, only if the user gave it; never guess. Optional."create_task2 fields changedInput schema / properties / allow_anonymised_example / descriptionPrevious value: -"Optional. Consent to publish this task as an anonymised example, under section 10 (Confidentiality) of the terms of service. Only set true if the client explicitly agreed to this. Overrides the value sent with request_quote. Default false; can be withdrawn by e-mail."New value: +"Optional. Consent to publish this task as an anonymised example (terms, section 10). Only true if the client explicitly agreed. Default false."Input schema / properties / terms_version / descriptionPrevious value: -"Version of the terms being accepted, currently 2026-09-28.2."New value: +"Version of the terms being accepted, currently 2026-09-28.3."get_status1 field changedInput schema / properties / message / descriptionPrevious value: -"Optional. Your reply to the operator: plain text, 1-2000 characters, never HTML. It is stored in the message thread (shown in messages as from: agent) and e-mailed to the operator; the answer is the usual status, including this message. Leave it out for a plain status check. The same call twice sends two messages."New value: +"Optional reply to the operator: plain text, 1-2000 characters. Leave it out for a plain status check."request_quote17 fields changedInput schema / properties / agentRemoved value: -{
- "properties": {
- "name": {
- "description": "Name of the agent or platform sending the request. Optional, for our records.",
- "maxLength": 200,
- "type": "string"
- }
- },
- "type": "object"
-}Input schema / properties / agent_name / descriptionPrevious value: -"Flat form of agent.name."New value: +"Name of the agent or platform. Optional."Input schema / properties / allow_anonymised_example / descriptionPrevious value: -"Consent to publish this task as an anonymised example (no names, addresses or personal data), under the confidentiality section of the terms of service. Only set true if the client explicitly agreed to this; otherwise omit the field or leave it false. Default false; can be withdrawn."New value: +"Consent to publish this task as an anonymised example. Only true if the client explicitly agreed. Default false."Input schema / properties / clientRemoved value: -{
- "properties": {
- "country": {
- "description": "Country of the operator, ISO 3166-1 alpha-2 (upper case). Optional, but include it whenever you can derive it (for example from the operator's address) rather than leaving it out or asking the user.",
- "pattern": "^[A-Z]{2}$",
- "type": "string"
- },
- "email": {
- "description": "E-mail of the operator. The quote, the payment link and the invoice go here.",
- "format": "email",
- "maxLength": 254,
- "pattern": "^[^\\s@]+@[^\\s@]+\\.[^\\s@]+$",
- "type": "string"
- },
- "name": {
- "description": "Full name of the person, or registered name of the company, that operates the agent. Optional, but include it whenever you know it (for example from a company name or address already in the conversation) rather than leaving it out or asking the user.",
- "maxLength": 200,
- "minLength": 1,
- "pattern": "^[^\\r\\n]+$",
- "type": "string"
- },
- "vat_id": {
- "description": "VAT or tax id of the operator, printed on the invoice. Optional.",
- "maxLength": 32,
- "type": "string"
- }
- },
- "required": [
- "email"
- ],
- "type": "object"
-}Input schema / properties / country / descriptionPrevious value: -"Flat form of client.country."New value: +"Operator's country, ISO 3166-1 alpha-2, upper case. Optional."Input schema / properties / currency / descriptionPrevious value: -"Flat form of task.currency."New value: +"EUR or USD. Default EUR."Input schema / properties / deadline / descriptionPrevious value: -"Flat form of task.deadline."New value: +"Latest acceptable delivery date, ISO 8601. Optional."Input schema / properties / deliverables / descriptionPrevious value: -"Flat form of task.deliverables."New value: +"What you expect to receive. Optional; otherwise put it in description."Input schema / properties / delivery_address / descriptionPrevious value: -"Flat form of task.delivery_address."New value: +"Required for a physical shipment. One plain string: recipient, street, postcode and city, country; a phone number last is optional."Input schema / properties / description / descriptionPrevious value: -"Flat form of task.description."New value: +"What is to be done, plainly: everything the user told you (quantity, material, colour, size, tolerances, what counts as done)."Input schema / properties / email / descriptionPrevious value: -"Flat form of client.email."New value: +"Contact e-mail of the operator; the quote goes here."Input schema / properties / input_files / descriptionPrevious value: -"Flat form of task.input_files."New value: +"HTTPS URLs of input files (photos, sketch, STEP/STL model, PDF drawing). At most 20."Input schema / properties / name / descriptionPrevious value: -"Flat form of client.name."New value: +"Required. The name of the person or company for the invoice."Input schema / properties / services / descriptionPrevious value: -"Flat form of task.services."New value: +"Service ids, if you know them."Input schema / properties / taskRemoved value: -{
- "properties": {
- "currency": {
- "description": "Currency of the quote. Default EUR.",
- "enum": [
- "EUR",
- "USD"
- ],
- "type": "string"
- },
- "deadline": {
- "description": "Latest acceptable delivery or dispatch date (ISO 8601). Optional; omit if the user gave none.",
- "format": "date",
- "maxLength": 32,
- "type": "string"
- },
- "deliverables": {
- "description": "What you expect to receive (item, files, report, photos, video). Optional - if you are not sure, leave it out and put it in task.description instead.",
- "maxLength": 5000,
- "type": "string"
- },
- "delivery_address": {
- "description": "Required whenever deliverables describes a physical item to be shipped, packed and collected, or handed over in person - omit only for purely digital deliverables (files, a report). One plain string with name, street, city, postcode and country, in that order; add a phone number at the end only if you already have one. Phone is optional - if you already have a name and an address, never stop to ask the user for a phone number. Not an object and not a list of lines.",
- "maxLength": 1000,
- "type": "string"
- },
- "description": {
- "description": "What is to be done, in plain language. Include quantities, materials, tolerances and what counts as done.",
- "maxLength": 20000,
- "type": "string"
- },
- "input_files": {
- "description": "HTTPS URLs of input files, for example photos, a sketch, a CAD model (STEP, STL), a PDF drawing, or other instructions, or attach the files to the e-mail. At most 20, each at most 2000 characters.",
- "items": {
- "maxLength": 2000,
- "pattern": "^https://",
- "type": "string"
- },
- "maxItems": 20,
- "type": "array"
- },
- "services": {
- "description": "Service ids from the service list, if you know them.",
- "items": {
- "enum": [
- "design",
- "make",
- "assemble",
- "measure",
- "test",
- "verify",
- "ship"
- ],
- "type": "string"
- },
- "type": "array"
- }
- },
- "required": [
- "description"
- ],
- "type": "object"
-}Input schema / properties / vat_id / descriptionPrevious value: -"Flat form of client.vat_id."New value: +"VAT or tax id for the invoice. Optional."Input schema / requiredAdded value: +[
+ "description",
+ "email",
+ "name"
+]create_task1 field changedInput schema / properties / terms_version / descriptionPrevious value: -"Version of the terms being accepted, currently 2026-09-28."New value: +"Version of the terms being accepted, currently 2026-09-28.2."get_status1 field changedInput schema / properties / messageAdded value: +{
+ "description": "Optional. Your reply to the operator: plain text, 1-2000 characters, never HTML. It is stored in the message thread (shown in messages as from: agent) and e-mailed to the operator; the answer is the usual status, including this message. Leave it out for a plain status check. The same call twice sends two messages.",
+ "type": "string"
+}create_task1 field changedInput schema / properties / terms_version / descriptionPrevious value: -"Version of the terms being accepted, currently 2026-09-26.2."New value: +"Version of the terms being accepted, currently 2026-09-28."request_quote12 fields changedInput schema / properties / agent_name / descriptionPrevious value: -"Name of the agent or platform sending the request. Optional, for our records."New value: +"Flat form of agent.name."Input schema / properties / country / descriptionPrevious value: -"Country of the operator, ISO 3166-1 alpha-2 (upper case). Optional, but include it whenever you can derive it (for example from the operator's address) rather than leaving it out or asking the user."New value: +"Flat form of client.country."Input schema / properties / currency / descriptionPrevious value: -"Currency of the quote. Default EUR."New value: +"Flat form of task.currency."Input schema / properties / deadline / descriptionPrevious value: -"Latest acceptable delivery or dispatch date (ISO 8601). Optional; omit if the user gave none."New value: +"Flat form of task.deadline."Input schema / properties / deliverables / descriptionPrevious value: -"What you expect to receive (item, files, report, photos, video). Optional - if you are not sure, leave it out and put it in task.description instead."New value: +"Flat form of task.deliverables."Input schema / properties / delivery_address / descriptionPrevious value: -"Required whenever deliverables describes a physical item to be shipped, packed and collected, or handed over in person - omit only for purely digital deliverables (files, a report). One plain string with name, street, city, postcode and country, in that order; add a phone number at the end only if you already have one. Phone is optional - if you already have a name and an address, never stop to ask the user for a phone number. Not an object and not a list of lines."New value: +"Flat form of task.delivery_address."Input schema / properties / description / descriptionPrevious value: -"What is to be done, in plain language. Include quantities, materials, tolerances and what counts as done."New value: +"Flat form of task.description."Input schema / properties / email / descriptionPrevious value: -"E-mail of the operator. The quote, the payment link and the invoice go here."New value: +"Flat form of client.email."Input schema / properties / input_files / descriptionPrevious value: -"HTTPS URLs of input files, for example photos, a sketch, a CAD model (STEP, STL), a PDF drawing, or other instructions, or attach the files to the e-mail. At most 20, each at most 2000 characters."New value: +"Flat form of task.input_files."Input schema / properties / name / descriptionPrevious value: -"Full name of the person, or registered name of the company, that operates the agent. Optional, but include it whenever you know it (for example from a company name or address already in the conversation) rather than leaving it out or asking the user."New value: +"Flat form of client.name."Input schema / properties / services / descriptionPrevious value: -"Service ids from the service list, if you know them."New value: +"Flat form of task.services."Input schema / properties / vat_id / descriptionPrevious value: -"VAT or tax id of the operator, printed on the invoice. Optional."New value: +"Flat form of client.vat_id."request_quote18 fields changedInput schema / properties / agent_nameAdded value: +{
+ "description": "Name of the agent or platform sending the request. Optional, for our records.",
+ "maxLength": 200,
+ "type": "string"
+}Input schema / properties / client / properties / country / descriptionPrevious value: -"Country of the operator, ISO 3166-1 alpha-2 (upper case)."New value: +"Country of the operator, ISO 3166-1 alpha-2 (upper case). Optional, but include it whenever you can derive it (for example from the operator's address) rather than leaving it out or asking the user."Input schema / properties / client / properties / name / descriptionPrevious value: -"Full name of the person, or registered name of the company, that operates the agent."New value: +"Full name of the person, or registered name of the company, that operates the agent. Optional, but include it whenever you know it (for example from a company name or address already in the conversation) rather than leaving it out or asking the user."Input schema / properties / client / requiredPrevious value: -[
- "email",
- "name",
- "country"
-]New value: +[
+ "email"
+]Input schema / properties / countryAdded value: +{
+ "description": "Country of the operator, ISO 3166-1 alpha-2 (upper case). Optional, but include it whenever you can derive it (for example from the operator's address) rather than leaving it out or asking the user.",
+ "pattern": "^[A-Z]{2}$",
+ "type": "string"
+}Input schema / properties / currencyAdded value: +{
+ "description": "Currency of the quote. Default EUR.",
+ "enum": [
+ "EUR",
+ "USD"
+ ],
+ "type": "string"
+}Input schema / properties / deadlineAdded value: +{
+ "description": "Latest acceptable delivery or dispatch date (ISO 8601). Optional; omit if the user gave none.",
+ "format": "date",
+ "maxLength": 32,
+ "type": "string"
+}Input schema / properties / deliverablesAdded value: +{
+ "description": "What you expect to receive (item, files, report, photos, video). Optional - if you are not sure, leave it out and put it in task.description instead.",
+ "maxLength": 5000,
+ "type": "string"
+}Input schema / properties / delivery_addressAdded value: +{
+ "description": "Required whenever deliverables describes a physical item to be shipped, packed and collected, or handed over in person - omit only for purely digital deliverables (files, a report). One plain string with name, street, city, postcode and country, in that order; add a phone number at the end only if you already have one. Phone is optional - if you already have a name and an address, never stop to ask the user for a phone number. Not an object and not a list of lines.",
+ "maxLength": 1000,
+ "type": "string"
+}Input schema / properties / descriptionAdded value: +{
+ "description": "What is to be done, in plain language. Include quantities, materials, tolerances and what counts as done.",
+ "maxLength": 20000,
+ "type": "string"
+}Input schema / properties / emailAdded value: +{
+ "description": "E-mail of the operator. The quote, the payment link and the invoice go here.",
+ "format": "email",
+ "maxLength": 254,
+ "pattern": "^[^\\s@]+@[^\\s@]+\\.[^\\s@]+$",
+ "type": "string"
+}Input schema / properties / input_filesAdded value: +{
+ "description": "HTTPS URLs of input files, for example photos, a sketch, a CAD model (STEP, STL), a PDF drawing, or other instructions, or attach the files to the e-mail. At most 20, each at most 2000 characters.",
+ "items": {
+ "maxLength": 2000,
+ "pattern": "^https://",
+ "type": "string"
+ },
+ "maxItems": 20,
+ "type": "array"
+}Input schema / properties / nameAdded value: +{
+ "description": "Full name of the person, or registered name of the company, that operates the agent. Optional, but include it whenever you know it (for example from a company name or address already in the conversation) rather than leaving it out or asking the user.",
+ "maxLength": 200,
+ "minLength": 1,
+ "pattern": "^[^\\r\\n]+$",
+ "type": "string"
+}Input schema / properties / servicesAdded value: +{
+ "description": "Service ids from the service list, if you know them.",
+ "items": {
+ "enum": [
+ "design",
+ "make",
+ "assemble",
+ "measure",
+ "test",
+ "verify",
+ "ship"
+ ],
+ "type": "string"
+ },
+ "type": "array"
+}Input schema / properties / task / properties / deliverables / descriptionPrevious value: -"What you expect to receive (item, files, report, photos, video)."New value: +"What you expect to receive (item, files, report, photos, video). Optional - if you are not sure, leave it out and put it in task.description instead."Input schema / properties / task / requiredPrevious value: -[
- "description",
- "deliverables"
-]New value: +[
+ "description"
+]Input schema / properties / vat_idAdded value: +{
+ "description": "VAT or tax id of the operator, printed on the invoice. Optional.",
+ "maxLength": 32,
+ "type": "string"
+}Input schema / requiredRemoved value: -[
- "task",
- "client"
-]request_quote2 fields changedInput schema / properties / task / properties / deadline / descriptionPrevious value: -"Latest acceptable delivery or dispatch date (ISO 8601)."New value: +"Latest acceptable delivery or dispatch date (ISO 8601). Optional; omit if the user gave none."Input schema / properties / task / properties / delivery_address / descriptionPrevious value: -"Required whenever deliverables describes a physical item to be shipped, packed and collected, or handed over in person - omit only for purely digital deliverables (files, a report). One plain string with name, street, city, postcode, country and phone together, in that order; not an object and not a list of lines."New value: +"Required whenever deliverables describes a physical item to be shipped, packed and collected, or handed over in person - omit only for purely digital deliverables (files, a report). One plain string with name, street, city, postcode and country, in that order; add a phone number at the end only if you already have one. Phone is optional - if you already have a name and an address, never stop to ask the user for a phone number. Not an object and not a list of lines."create_task1 field changedInput schema / properties / allow_anonymised_example / descriptionPrevious value: -"Optional. Consent to publish this task as an anonymised example, under section 10 (Confidentiality) of the terms of service. Overrides the value sent with request_quote. Default false; can be withdrawn by e-mail."New value: +"Optional. Consent to publish this task as an anonymised example, under section 10 (Confidentiality) of the terms of service. Only set true if the client explicitly agreed to this. Overrides the value sent with request_quote. Default false; can be withdrawn by e-mail."list_services1 field changedInput schema / properties / fullAdded value: +{
+ "default": false,
+ "description": "true for the complete document (same as /services.json); false (default) for a short summary.",
+ "type": "boolean"
+}request_quote2 fields changedInput schema / properties / allow_anonymised_example / descriptionPrevious value: -"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."New value: +"Consent to publish this task as an anonymised example (no names, addresses or personal data), under the confidentiality section of the terms of service. Only set true if the client explicitly agreed to this; otherwise omit the field or leave it false. Default false; can be withdrawn."Input schema / properties / task / properties / delivery_address / descriptionPrevious value: -"Name, street, city, postcode, country and phone of the recipient, if something is shipped."New value: +"Required whenever deliverables describes a physical item to be shipped, packed and collected, or handed over in person - omit only for purely digital deliverables (files, a report). One plain string with name, street, city, postcode, country and phone together, in that order; not an object and not a list of lines."create_task1 field changedInput schema / properties / terms_version / descriptionPrevious value: -"Version of the terms being accepted, currently 2026-09-25."New value: +"Version of the terms being accepted, currently 2026-09-26.2."create_task1 field changedInput schema / properties / terms_version / descriptionPrevious value: -"Version of the terms being accepted, currently 2026-09-17.3."New value: +"Version of the terms being accepted, currently 2026-09-25."request_quote17 fields changedInput schema / properties / agent / properties / name / maxLengthAdded value: +200Input schema / properties / client / properties / country / descriptionPrevious value: -"Country of the operator, ISO 3166-1 alpha-2."New value: +"Country of the operator, ISO 3166-1 alpha-2 (upper case)."Input schema / properties / client / properties / country / patternAdded value: +"^[A-Z]{2}$"Input schema / properties / client / properties / email / maxLengthAdded value: +254Input schema / properties / client / properties / email / patternAdded value: +"^[^\\s@]+@[^\\s@]+\\.[^\\s@]+$"Input schema / properties / client / properties / name / maxLengthAdded value: +200Input schema / properties / client / properties / name / minLengthAdded value: +1Input schema / properties / client / properties / name / patternAdded value: +"^[^\\r\\n]+$"Input schema / properties / client / properties / vat_id / maxLengthAdded value: +32Input schema / properties / task / properties / deadline / maxLengthAdded value: +32Input schema / properties / task / properties / deliverables / maxLengthAdded value: +5000Input schema / properties / task / properties / delivery_address / maxLengthAdded value: +1000Input schema / properties / task / properties / description / maxLengthAdded value: +20000Input schema / properties / task / properties / input_files / descriptionPrevious value: -"HTTPS URLs of input files, for example photos, a sketch, a CAD model (STEP, STL), a PDF drawing, or other instructions, or attach the files to the e-mail."New value: +"HTTPS URLs of input files, for example photos, a sketch, a CAD model (STEP, STL), a PDF drawing, or other instructions, or attach the files to the e-mail. At most 20, each at most 2000 characters."Input schema / properties / task / properties / input_files / items / maxLengthAdded value: +2000Input schema / properties / task / properties / input_files / items / patternAdded value: +"^https://"Input schema / properties / task / properties / input_files / maxItemsAdded value: +20request_quote1 field changedInput schema / properties / task / properties / input_files / descriptionPrevious value: -"HTTPS URLs of input files (STL, STEP, PDF, instructions), or attach the files to the e-mail."New value: +"HTTPS URLs of input files, for example photos, a sketch, a CAD model (STEP, STL), a PDF drawing, or other instructions, or attach the files to the e-mail."
Add one secure layer between your agents and this server.