Skip to main content
Glama

Hands for Agents

by com.handsforagents
OverviewDiscussionsAdmin

Server Details

Human-operated physical world in the EU: make, assemble, measure, verify, ship.

If you are the author of this connector, you can claim ownership by verifying the domain or GitHub account it belongs to. Claimed connector authors can inspect health checks, view analytics, and manage their listing.
Status
Healthy
Uptime
100.0% over 23 days
Last Tested
Transport
Streamable HTTP · MCP 2025-11-25
URL
Repository
handsforagents/handsforagents-mcp
GitHub Stars
0
Server Listing
handsforagents-mcp

TDQS

A4.3/5.0

Scored across 5 tools

Disambiguation5/5

Each tool maps to a distinct stage in the quote-to-delivery workflow: requesting a quote, creating a task, checking status, confirming delivery, and listing service details. Although get_status can also send a message, its primary purpose remains status retrieval and does not overlap with other tools.

Naming Consistency5/5

All five tools follow the same verb_noun snake_case convention: confirm_delivery, create_task, get_status, list_services, request_quote. The pattern is predictable and immediately readable.

Tool Count5/5

Five tools are well-scoped for this service. Each tool earns its place by covering a necessary step: discovery, quoting, task creation, monitoring, and delivery confirmation.

Completeness4/5

The core lifecycle from quote request through task creation, status tracking, and delivery confirmation is covered. Minor gaps exist, such as no explicit cancel_task, list_tasks, or file-upload tool, though the upload URL is provided by request_quote.

Available Tools

5 tools
confirm_deliveryConfirm or dispute deliveryA
Destructive
Inspect

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.

ParametersJSON Schema
NameRequiredDescriptionDefault
reasonNoRequired when accepted is false: what differs from the quote.
task_idYesId of the task, of the form t_...
acceptedYestrue accepts the delivery, false disputes it.
access_tokenYesAccess token of the quote and its task, issued with the quote.

TDQS

A4.3/5.0
Behavior4/5

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.

Conciseness4/5

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.

Completeness4/5

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.

Parameters4/5

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.

Purpose5/5

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.

Usage Guidelines4/5

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.

create_taskAccept quote, get payment linkA
Idempotent
Inspect

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.

ParametersJSON Schema
NameRequiredDescriptionDefault
quote_idYesId of the quote, of the form q_...
access_tokenYesAccess token of the quote and its task, issued with the quote.
terms_versionYesVersion of the terms being accepted, currently 2026-09-29.
terms_acceptedYesAcceptance of https://handsforagents.com/terms.html by the operator.
allow_anonymised_exampleNoOptional. Consent to publish this task as an anonymised example (terms, section 10); true only when the client explicitly agreed. Default false.

TDQS

A4.6/5.0
Behavior5/5

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.

Conciseness4/5

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.

Completeness5/5

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.

Parameters4/5

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.

Purpose5/5

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.

Usage Guidelines4/5

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.

get_statusGet status or answer operatorAInspect

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.

ParametersJSON Schema
NameRequiredDescriptionDefault
idYesquote_id or task_id.
fullNotrue returns the complete answer.
messageNoOptional reply to the operator: plain text, 1-2000 characters. Without it the call is a plain status check.
access_tokenYesAccess token of the quote and its task, issued with the quote.

TDQS

A4.1/5.0
Behavior5/5

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.

Conciseness4/5

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.

Completeness5/5

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.

Parameters4/5

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.

Purpose4/5

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.

Usage Guidelines3/5

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.

list_servicesList servicesA
Read-onlyIdempotent
Inspect

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.

ParametersJSON Schema
NameRequiredDescriptionDefault
fullNotrue returns the complete document (the same as /services.json); false (default) returns a short summary.

TDQS

A3.8/5.0
Behavior4/5

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.

Conciseness4/5

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.

Completeness4/5

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.

Parameters4/5

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.

Purpose4/5

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.

Usage Guidelines3/5

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.

request_quoteRequest a quoteAInspect

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"]}

ParametersJSON Schema
NameRequiredDescriptionDefault
nameYesRequired. The person or company on the invoice, normally the recipient or company in delivery_address.
emailYesContact e-mail of the operator; the quote is sent here.
vat_idNoVAT or tax id for the invoice, as given by the client. Optional.
countryNoOperator's country, ISO 3166-1 alpha-2, upper case, normally that of the delivery address. Optional.
currencyNoEUR or USD. Default EUR.
deadlineNoLatest acceptable delivery date, ISO 8601. Optional.
servicesNoService ids. Optional.
agent_nameNoName of the agent or platform. Optional.
descriptionYesWhat is to be done, plainly: quantity, material, colour, size, tolerances, what counts as done.
input_filesNoHTTPS URLs of input files (photos, sketch, STEP/STL model, PDF drawing). At most 20.
deliverablesNoWhat the client expects to receive. Optional; otherwise part of description.
delivery_addressNoRequired 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_exampleNoConsent to publish this task as an anonymised example; true only when the client explicitly agreed. Default false.

TDQS

A4.6/5.0
Behavior5/5

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.

Conciseness4/5

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.

Completeness5/5

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.

Parameters4/5

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.

Purpose5/5

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.

Usage Guidelines4/5

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.

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

  1. 5 tool updates
    • Changedconfirm_delivery3 fields changed
      • addedInput schema / properties / accepted / description
        Added value: +"true accepts the delivery, false disputes it."
      • changedInput schema / properties / access_token / description
        Previous value: -"Token returned by request_quote."New value: +"Access token of the quote and its task, issued with the quote."
      • addedInput schema / properties / task_id / description
        Added value: +"Id of the task, of the form t_..."
    • Changedcreate_task3 fields changed
      • changedInput schema / properties / access_token / description
        Previous value: -"Token returned by request_quote."New value: +"Access token of the quote and its task, issued with the quote."
      • changedInput schema / properties / allow_anonymised_example / description
        Previous 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."
      • addedInput schema / properties / quote_id / description
        Added value: +"Id of the quote, of the form q_..."
    • Changedget_status3 fields changed
      • changedInput schema / properties / access_token / description
        Previous value: -"Token returned by request_quote."New value: +"Access token of the quote and its task, issued with the quote."
      • changedInput schema / properties / full / description
        Previous value: -"true: the complete answer."New value: +"true returns the complete answer."
      • changedInput schema / properties / message / description
        Previous 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."
    • Changedlist_services1 field changed
      • changedInput schema / properties / full / description
        Previous 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."
    • Changedrequest_quote9 fields changed
      • changedInput schema / properties / allow_anonymised_example / description
        Previous 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."
      • changedInput schema / properties / country / description
        Previous 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."
      • changedInput schema / properties / deliverables / description
        Previous 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."
      • changedInput schema / properties / delivery_address / description
        Previous 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."
      • changedInput schema / properties / description / description
        Previous 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."
      • changedInput schema / properties / email / description
        Previous value: -"Contact e-mail of the operator; the quote goes here."New value: +"Contact e-mail of the operator; the quote is sent here."
      • changedInput schema / properties / name / description
        Previous 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."
      • changedInput schema / properties / services / description
        Previous value: -"Service ids, if you know them."New value: +"Service ids. Optional."
      • changedInput schema / properties / vat_id / description
        Previous 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."
  2. 1 tool update
    • Changedcreate_task1 field changed
      • changedInput schema / properties / terms_version / description
        Previous value: -"Version of the terms being accepted, currently 2026-09-28.3."New value: +"Version of the terms being accepted, currently 2026-09-29."
  3. 2 tool updates
    • Changedget_status1 field changed
      • addedInput schema / properties / full
        Added value: +{
+  "default": false,
+  "description": "true: the complete answer.",
+  "type": "boolean"
+}
    • Changedrequest_quote2 fields changed
      • changedInput schema / properties / delivery_address / description
        Previous 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."
      • changedInput schema / properties / vat_id / description
        Previous 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."
  4. 3 tool updates
    • Changedcreate_task2 fields changed
      • changedInput schema / properties / allow_anonymised_example / description
        Previous 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."
      • changedInput schema / properties / terms_version / description
        Previous 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."
    • Changedget_status1 field changed
      • changedInput schema / properties / message / description
        Previous 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."
    • Changedrequest_quote17 fields changed
      • removedInput schema / properties / agent
        Removed value: -{
-  "properties": {
-    "name": {
-      "description": "Name of the agent or platform sending the request. Optional, for our records.",
-      "maxLength": 200,
-      "type": "string"
-    }
-  },
-  "type": "object"
-}
      • changedInput schema / properties / agent_name / description
        Previous value: -"Flat form of agent.name."New value: +"Name of the agent or platform. Optional."
      • changedInput schema / properties / allow_anonymised_example / description
        Previous 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."
      • removedInput schema / properties / client
        Removed 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"
-}
      • changedInput schema / properties / country / description
        Previous value: -"Flat form of client.country."New value: +"Operator's country, ISO 3166-1 alpha-2, upper case. Optional."
      • changedInput schema / properties / currency / description
        Previous value: -"Flat form of task.currency."New value: +"EUR or USD. Default EUR."
      • changedInput schema / properties / deadline / description
        Previous value: -"Flat form of task.deadline."New value: +"Latest acceptable delivery date, ISO 8601. Optional."
      • changedInput schema / properties / deliverables / description
        Previous value: -"Flat form of task.deliverables."New value: +"What you expect to receive. Optional; otherwise put it in description."
      • changedInput schema / properties / delivery_address / description
        Previous 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."
      • changedInput schema / properties / description / description
        Previous 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)."
      • changedInput schema / properties / email / description
        Previous value: -"Flat form of client.email."New value: +"Contact e-mail of the operator; the quote goes here."
      • changedInput schema / properties / input_files / description
        Previous value: -"Flat form of task.input_files."New value: +"HTTPS URLs of input files (photos, sketch, STEP/STL model, PDF drawing). At most 20."
      • changedInput schema / properties / name / description
        Previous value: -"Flat form of client.name."New value: +"Required. The name of the person or company for the invoice."
      • changedInput schema / properties / services / description
        Previous value: -"Flat form of task.services."New value: +"Service ids, if you know them."
      • removedInput schema / properties / task
        Removed 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"
-}
      • changedInput schema / properties / vat_id / description
        Previous value: -"Flat form of client.vat_id."New value: +"VAT or tax id for the invoice. Optional."
      • addedInput schema / required
        Added value: +[
+  "description",
+  "email",
+  "name"
+]
  5. 2 tool updates
    • Changedcreate_task1 field changed
      • changedInput schema / properties / terms_version / description
        Previous value: -"Version of the terms being accepted, currently 2026-09-28."New value: +"Version of the terms being accepted, currently 2026-09-28.2."
    • Changedget_status1 field changed
      • addedInput schema / properties / message
        Added 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"
+}
  6. 1 tool update
    • Changedcreate_task1 field changed
      • changedInput schema / properties / terms_version / description
        Previous value: -"Version of the terms being accepted, currently 2026-09-26.2."New value: +"Version of the terms being accepted, currently 2026-09-28."
  7. 1 tool update
    • Changedrequest_quote12 fields changed
      • changedInput schema / properties / agent_name / description
        Previous value: -"Name of the agent or platform sending the request. Optional, for our records."New value: +"Flat form of agent.name."
      • changedInput schema / properties / country / description
        Previous 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."
      • changedInput schema / properties / currency / description
        Previous value: -"Currency of the quote. Default EUR."New value: +"Flat form of task.currency."
      • changedInput schema / properties / deadline / description
        Previous value: -"Latest acceptable delivery or dispatch date (ISO 8601). Optional; omit if the user gave none."New value: +"Flat form of task.deadline."
      • changedInput schema / properties / deliverables / description
        Previous 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."
      • changedInput schema / properties / delivery_address / description
        Previous 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."
      • changedInput schema / properties / description / description
        Previous 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."
      • changedInput schema / properties / email / description
        Previous value: -"E-mail of the operator. The quote, the payment link and the invoice go here."New value: +"Flat form of client.email."
      • changedInput schema / properties / input_files / description
        Previous 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."
      • changedInput schema / properties / name / description
        Previous 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."
      • changedInput schema / properties / services / description
        Previous value: -"Service ids from the service list, if you know them."New value: +"Flat form of task.services."
      • changedInput schema / properties / vat_id / description
        Previous value: -"VAT or tax id of the operator, printed on the invoice. Optional."New value: +"Flat form of client.vat_id."
  8. 1 tool update
    • Changedrequest_quote18 fields changed
      • addedInput schema / properties / agent_name
        Added value: +{
+  "description": "Name of the agent or platform sending the request. Optional, for our records.",
+  "maxLength": 200,
+  "type": "string"
+}
      • changedInput schema / properties / client / properties / country / description
        Previous 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."
      • changedInput schema / properties / client / properties / name / description
        Previous 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."
      • changedInput schema / properties / client / required
        Previous value: -[
-  "email",
-  "name",
-  "country"
-]New value: +[
+  "email"
+]
      • addedInput schema / properties / country
        Added 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"
+}
      • addedInput schema / properties / currency
        Added value: +{
+  "description": "Currency of the quote. Default EUR.",
+  "enum": [
+    "EUR",
+    "USD"
+  ],
+  "type": "string"
+}
      • addedInput schema / properties / deadline
        Added value: +{
+  "description": "Latest acceptable delivery or dispatch date (ISO 8601). Optional; omit if the user gave none.",
+  "format": "date",
+  "maxLength": 32,
+  "type": "string"
+}
      • addedInput schema / properties / deliverables
        Added 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"
+}
      • addedInput schema / properties / delivery_address
        Added 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"
+}
      • addedInput schema / properties / description
        Added value: +{
+  "description": "What is to be done, in plain language. Include quantities, materials, tolerances and what counts as done.",
+  "maxLength": 20000,
+  "type": "string"
+}
      • addedInput schema / properties / email
        Added 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"
+}
      • addedInput schema / properties / input_files
        Added 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"
+}
      • addedInput schema / properties / name
        Added 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"
+}
      • addedInput schema / properties / services
        Added 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"
+}
      • changedInput schema / properties / task / properties / deliverables / description
        Previous 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."
      • changedInput schema / properties / task / required
        Previous value: -[
-  "description",
-  "deliverables"
-]New value: +[
+  "description"
+]
      • addedInput schema / properties / vat_id
        Added value: +{
+  "description": "VAT or tax id of the operator, printed on the invoice. Optional.",
+  "maxLength": 32,
+  "type": "string"
+}
      • removedInput schema / required
        Removed value: -[
-  "task",
-  "client"
-]
  9. 1 tool update
    • Changedrequest_quote2 fields changed
      • changedInput schema / properties / task / properties / deadline / description
        Previous 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."
      • changedInput schema / properties / task / properties / delivery_address / description
        Previous 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."
  10. 3 tool updates
    • Changedcreate_task1 field changed
      • changedInput schema / properties / allow_anonymised_example / description
        Previous 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."
    • Changedlist_services1 field changed
      • addedInput schema / properties / full
        Added value: +{
+  "default": false,
+  "description": "true for the complete document (same as /services.json); false (default) for a short summary.",
+  "type": "boolean"
+}
    • Changedrequest_quote2 fields changed
      • changedInput schema / properties / allow_anonymised_example / description
        Previous 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."
      • changedInput schema / properties / task / properties / delivery_address / description
        Previous 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."
  11. 1 tool update
    • Changedcreate_task1 field changed
      • changedInput schema / properties / terms_version / description
        Previous value: -"Version of the terms being accepted, currently 2026-09-25."New value: +"Version of the terms being accepted, currently 2026-09-26.2."
  12. 2 tool updates
    • Changedcreate_task1 field changed
      • changedInput schema / properties / terms_version / description
        Previous value: -"Version of the terms being accepted, currently 2026-09-17.3."New value: +"Version of the terms being accepted, currently 2026-09-25."
    • Changedrequest_quote17 fields changed
      • addedInput schema / properties / agent / properties / name / maxLength
        Added value: +200
      • changedInput schema / properties / client / properties / country / description
        Previous value: -"Country of the operator, ISO 3166-1 alpha-2."New value: +"Country of the operator, ISO 3166-1 alpha-2 (upper case)."
      • addedInput schema / properties / client / properties / country / pattern
        Added value: +"^[A-Z]{2}$"
      • addedInput schema / properties / client / properties / email / maxLength
        Added value: +254
      • addedInput schema / properties / client / properties / email / pattern
        Added value: +"^[^\\s@]+@[^\\s@]+\\.[^\\s@]+$"
      • addedInput schema / properties / client / properties / name / maxLength
        Added value: +200
      • addedInput schema / properties / client / properties / name / minLength
        Added value: +1
      • addedInput schema / properties / client / properties / name / pattern
        Added value: +"^[^\\r\\n]+$"
      • addedInput schema / properties / client / properties / vat_id / maxLength
        Added value: +32
      • addedInput schema / properties / task / properties / deadline / maxLength
        Added value: +32
      • addedInput schema / properties / task / properties / deliverables / maxLength
        Added value: +5000
      • addedInput schema / properties / task / properties / delivery_address / maxLength
        Added value: +1000
      • addedInput schema / properties / task / properties / description / maxLength
        Added value: +20000
      • changedInput schema / properties / task / properties / input_files / description
        Previous 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."
      • addedInput schema / properties / task / properties / input_files / items / maxLength
        Added value: +2000
      • addedInput schema / properties / task / properties / input_files / items / pattern
        Added value: +"^https://"
      • addedInput schema / properties / task / properties / input_files / maxItems
        Added value: +20
  13. 1 tool update
    • Changedrequest_quote1 field changed
      • changedInput schema / properties / task / properties / input_files / description
        Previous 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."
  14. 4 tool updates
    • Addedconfirm_delivery
    • Addedcreate_task
    • Changedget_status3 fields changed
      • removedInput schema / additionalProperties
        Removed value: -false
      • changedInput schema / properties / access_token / description
        Previous value: -"The access_token returned by request_quote."New value: +"Token returned by request_quote."
      • changedInput schema / properties / id / description
        Previous value: -"The quote_id returned by request_quote."New value: +"quote_id or task_id."
    • Changedlist_services2 fields changed
      • removedInput schema / additionalProperties
        Removed value: -false
      • addedInput schema / properties
        Added value: +{}

Related MCP Connectors

Related MCP Servers

  • a2a2p

    Deadlypillow
    F
    license
    Not graded
    quality
    A
    maintenance
    a2a2p is an open protocol for turning intent into physical things: describe what must be true about the world (holds 15 kg, outdoors, ten years) and get back a manufacturable specification, a deterministic engineering review, and a price. The specification is public domain (CC0) and implementable by anyone; a2a2p.com is a free reference implementation with no API key required.
    -

  • eu-verify

    contentfactory
    A
    license
    Not graded
    quality
    D
    maintenance
    eu-verify lets AI agents verify any European business partner: company existence (official French SIREN registry), insolvency records (BODACC), EU VAT validation before invoicing (VIES), SIRET/IBAN/LEI checks, address and email verification, French business-day deadlines and EU public tenders. 10 paid MCP tools + a free catalog tool, plus 81 HTTP endpoints. Each call costs $0.001-$0.01 in USDC on
    1
    MIT

  • viridis-agent-fleet

    jdhart81
    A
    license
    C
    quality
    A
    maintenance
    MCP services for agent security preflight, source scanning, injection screening, proof-of-work policy rehearsal, carbon accounting, climate disclosure and regulatory monitoring. Use each hosted endpoint in the README. Inspect a free quote before buyer-authorized x402/USDC payment. Includes free trust and settlement tools. Maxwell rehearsal does not activate runtime protection.
    220
    Apache 2.0
Try in Browser
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources