a2a2p — Agent-to-Agent-to-Physical

render_supplier_email_binding

Render the caller's requirement as a reviewable RFC 5322 supplier-email draft after rebuilding its canonical supplier package and repeating quote-stage screening. The plain-language draft offers optional Can quote / Need changes / Decline reply choices and asks for price basis, freight scope, and lead-time basis when quoting. Suppliers may still reply in normal prose. Only an allow verdict renders. The operation validates one explicit recipient and an accountable sender-domain envelope, but cannot verify SPF, DKIM, or DMARC and therefore returns sendable=false. An explicit specification.assembly with two or more parts returns decomposition_required before file inspection or rendering. It is a stateless artifact transformation only: it stores nothing, sends nothing, contacts no supplier or provider, and grants no quote, order, payment, or fabrication authority.

Input Schema

TableJSON Schema

Name	Required	Description
`intent`	No	Layer 1 — the problem. What the physical matter needs to DO. Use this for intent-driven requests where the agent describes purpose and a2a2p recommends solutions.
`contact`	No	Optional email or callback endpoint for quote delivery.
`deadline`	No	Required delivery date or timeframe. Maps to intent.timeline.
`quantity`	No	Number of units needed. Maps to intent.quantity.
`budget_usd`	No	Approximate budget in USD. Maps to intent.budget_envelope.
`constraints`	No	Hard constraints: tolerances, certifications, materials to avoid, size/weight limits. Maps to intent.functional_requirements.
`requirement`	No	Plain-language description of the physical need. Maps to intent.purpose. Include function, dimensions, materials, load/performance requirements, environment, and interfaces where known.
`callback_url`	No	Optional HTTPS URL. When the quote is ready, a2a2p POSTs it as JSON to this URL.
`email_binding`	Yes	Explicit envelope for a reviewable, non-sending RFC 5322 draft. No address is looked up or inferred.
`specification`	No	Layer 2 — the solution. What the physical matter IS. Populate what is known. Precise specifications produce faster, tighter quotes. Controlled vocabularies are preferred but open values are accepted.
`business_context`	No	Optional business requirements (expected volumes, cost targets, ROI constraints). If provided, the quote includes a business case.
`rejected_alternatives`	No	Options already considered and ruled out. Prevents re-suggesting and builds the learning corpus.

Output Schema

TableJSON Schema

Name	Required	Description	Default
`status`	Yes
`version`	Yes
`artifact`	Yes
`contract`	Yes
`sendable`	Yes
`authority`	Yes
`provenance`	Yes
`conformance`	Yes
`binding_sha256`	Yes
`digest_semantics`	Yes
`sender_authentication`	Yes
`reply_route_verification`	Yes
`requirements_before_sending`	Yes

Schema Changelog

Changes observed during successful MCP inspections. Dates show when Glama detected each change.

Changed1 schema field changedSep 2, 2026
- changedOutput schema / properties / version / const
```
Previous value: -"1.2.0"New value: +"1.3.0"
```

Changed1 schema field changedSep 1, 2026

changedInput schema / properties / specification / properties / process / enum

Previous value: -[
-  "cnc_milling",
-  "cnc_turning",
-  "fdm_3d_print",
-  "sla_3d_print",
-  "sls_3d_print",
-  "sheet_metal",
-  "casting",
-  "injection_molding",
-  "extrusion"
-]New value: +[
+  "cnc_milling",
+  "cnc_turning",
+  "fdm_3d_print",
+  "sla_3d_print",
+  "sls_3d_print",
+  "sheet_metal",
+  "laser_cutting",
+  "casting",
+  "injection_molding",
+  "extrusion"
+]

Changed1 schema field changedSep 1, 2026
- changedOutput schema / properties / version / const
```
Previous value: -"1.1.0"New value: +"1.2.0"
```

Changed1 schema field changedAug 25, 2026

added

Input schema / properties / intent / properties / functional_requirements / properties / load_case / properties / allowable_shear_stress_mpa

Added value: +{
+  "description": "Optional requester-supplied transverse-shear design allowable; evaluated independently and never inferred from handbook data.",
+  "exclusiveMinimum": 0,
+  "type": "number"
+}

Changed5 schema fields changedAug 25, 2026
- changedInput schema / properties / intent / properties / purpose / description
```
Previous value: -"What the physical matter needs to accomplish (one line minimum, required)."New value: +"What the physical matter needs to accomplish (one non-whitespace line minimum, required)."
```
- addedInput schema / properties / intent / properties / purpose / minLength
```
Added value: +1
```
- addedInput schema / properties / intent / properties / purpose / pattern
```
Added value: +"\\S"
```
- addedInput schema / properties / requirement / minLength
```
Added value: +1
```
- addedInput schema / properties / requirement / pattern
```
Added value: +"\\S"
```

Changed3 schema fields changedAug 20, 2026

addedInput schema / properties / email_binding / allOf

Added value: +[
+  {
+    "if": {
+      "properties": {
+        "principal_kind": {
+          "const": "organization"
+        }
+      },
+      "required": [
+        "principal_kind"
+      ]
+    },
+    "then": {
+      "required": [
+        "principal_registered_address"
+      ]
+    }
+  }
+]

addedInput schema / properties / email_binding / properties / principal_registered_address

Added value: +{
+  "description": "Required when principal_kind is organization.",
+  "maxLength": 500,
+  "minLength": 1,
+  "type": "string"
+}

changedOutput schema / properties / version / const
```
Previous value: -"1.0.0"New value: +"1.1.0"
```

AddedAug 11, 2026

TDQS

A4.5/5.0

Behavior5/5

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

No annotations are provided, so the description carries the full burden — and it delivers extensively. It discloses the allow-verdict gate, the sendable=false limitation due to unverifiable SPF/DKIM/DMARC, the decomposition_required early return for multi-part assemblies, and an explicit statelessness guarantee (stores nothing, sends nothing, contacts no one, grants no authority). This is exemplary side-effect and limitation disclosure.

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?

The description is long but every sentence earns its place: purpose, draft content, gating, validation limitation, guardrail, and side-effect profile each occupy one dense unit, and the primary purpose is front-loaded first. It is information-dense rather than padded, though an agent must parse several clauses before reaching the simplest takeaway.

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 tool with 12 parameters, nested objects, and an output schema, the description covers nearly everything an agent needs: preconditions, render gating, validation behavior, limitations, early-return cases, and the no-side-effect profile. The one notable gap is that it references "specification.assembly" as a guardrail trigger, but no such property appears in the visible specification schema — a minor inconsistency that could confuse an agent.

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 description coverage is 100%, setting a baseline of 3. The description adds value beyond the schema by explaining envelope validation behavior — "validates one explicit recipient and an accountable sender-domain envelope" — which gives the email_binding parameters (recipient, from, principal_domain, reply_to) operational meaning not present in their individual schema descriptions.

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 opening clause states a specific verb and resource — "Render the caller's requirement as a reviewable RFC 5322 supplier-email draft" — and frames it as a post-processing step (after rebuilding the canonical supplier package and repeating quote-stage screening). This clearly distinguishes it from siblings like build_supplier_request_package (which builds a package, not a draft) and request_provider_estimate (which requests an estimate, not a reviewable artifact).

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?

The description conveys clear usage context: it runs after package rebuilding and quote-stage screening, renders only on an allow verdict, and is a pure artifact transformation that sends nothing. However, it never names an alternative tool or states an explicit when-not-to-use condition, so routing among the 23 siblings is left partly to inference.

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

All a2a2p — Agent-to-Agent-to-Physical tools Inspect

Try in Browser

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A3.8/5.0

Disambiguation2/5

Multiple tool clusters have near-identical names and responsibilities: prepare_derived_beam_simulation, prepare_reviewed_beam_simulation, and prepare_simulation_study all produce bounded simulation studies, while the validate_* family has five variants with subtle input differences. The descriptions are detailed, but an agent would frequently need to read an entire paragraph to avoid misselection.

Naming Consistency5/5

All 24 tools follow the same snake_case verb_noun pattern: build_, check_, request_, validate_, prepare_, run_, upload_, etc. There are no camelCase names, no vague single-word tools, and no stylistic outliers.

Tool Count3/5

24 tools is at the heavy end of the calibration range, and a large subset of rectangular-beam preparation/validation tools could be consolidated. The broad physical-request and supplier pipeline justifies some of the count, but the overall surface still feels over-scoped.

Completeness4/5

The core workflows are covered: upload, submit, revise, status, spec review, pricing/estimates, quote-job polling, supplier package/email rendering, and a full bounded simulation loop. Missing cancellation, request listing, and actual supplier send/order actions are real but peripheral gaps rather than workflow-killing dead ends.

render_supplier_email_binding

Input Schema

Output Schema

Schema Changelog

TDQS

Glama MCP Gateway

TDQS

Resources