Skip to main content
Glama

a2a2p — Agent-to-Agent-to-Physical

review_specification

Instant, synchronous engineering review of a physical requirement — nothing is submitted or stored. Purpose prose is preserved as intent but is not silently converted into loads, geometry, environments, interfaces, or acceptance criteria. The versioned engineering_evaluation receipt lists canonical paths and exact checks run, reports not_evaluated when none ran, and denies engineering-validation, certification, physical-truth, supplier-acceptance, and fabrication authority. Its finding-penalty score is not engineering soundness. Deterministic checks: material identification with handbook-typical properties (density, stiffness, yield, service temperature), explicit rectangular beam deflection, nominal bending stress, and nominal transverse shear with requester-defined acceptance criteria, material/process compatibility, tolerance-vs-process reality, quantity economics (e.g. tooling amortization), environment fit (UV, saltwater, food contact, temperature, medical), flexibility fit, post-processing validity, design-file format fit, and specification completeness. Every matched material reference identifies the current table as an uncited compilation and explicitly denies source verification, exact-state verification, design-allowable use, and simulation eligibility. A criterion that depends on that reference remains not_evaluated; its numerical comparison is reference_only, never a pass, failure, or blocker. Every supplied limit or strength basis is labeled requester_assertion, and every criterion verdict is explicitly conditional on declared inputs and the bounded model—not engineering validation or design certification. Returns findings ranked blocker/warning/info, two readiness scores, and a deterministic clarification_plan: compact next_fields, visible remaining_fields, optional CAD accelerators, an intent-only resolution handoff, next_call with the recommended exact MCP/REST continuation, and continuation_options for every operation explicitly eligible from a complete specification. Examples are shapes, never invented defaults. For a decomposed design, send specification.assembly with parts and interfaces: a2a2p then checks galvanic pairing and interface fit across parts, which a single-part review cannot, and prices each part separately. Two or more explicitly declared parts always classify as assembly_or_system and can never become quote_ready as one part, regardless of purpose wording or top-level part fields. Undeclared interfaces are unchecked — nothing is inferred. CHECK intake_classification first. a2a2p reviews one manufacturable part at a time; a request naming a behaviour rather than an object ("a device that detects and removes debris") is classified capability_concept and redirected to decomposition, because no material or tolerance can be derived from it. The classification is advisory, never blocks, and defers to any supplied specification. READ resolution_readiness, not quote_readiness, while you are still answering questions. quote_readiness is supplier-facing and stays capped by material/process/dimensions/tolerance that a2a2p derives for you, so it cannot reach quote_ready from intent alone however much you supply. resolution_readiness measures only what the requester owns and reaches ready_to_resolve once you have supplied enough to derive a specification — which is not a supplier quote. completeness.awaiting_requester and completeness.derivable_by_resolution say which fields are whose. Accepts the same input as request_physical_solution (structured intent/specification or legacy flat fields). Forward-compatible fields remain accepted, but uninterpreted_fields names every supplied path in the declared review scope whose value did not influence deterministic engineering checks, uses bounded and privacy-safe RFC 6901 JSON Pointers, caps unqualified ready grades, and provides non-inferential repair guidance; never read HTTP success alone as proof that every field was understood. For intent_only, complete requester context leads to submit_for_specification_resolution; for a supplied specification, apply only facts you know, re-review until quote_ready, then submit if a durable resolution is useful.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
intentNoLayer 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.
contactNoOptional email or callback endpoint for quote delivery.
deadlineNoRequired delivery date or timeframe. Maps to intent.timeline.
quantityNoNumber of units needed. Maps to intent.quantity.
budget_usdNoApproximate budget in USD. Maps to intent.budget_envelope.
constraintsNoHard constraints: tolerances, certifications, materials to avoid, size/weight limits. Maps to intent.functional_requirements.
requirementNoPlain-language description of the physical need. Maps to intent.purpose. Include function, dimensions, materials, load/performance requirements, environment, and interfaces where known.
callback_urlNoOptional HTTPS URL. When the quote is ready, a2a2p POSTs it as JSON to this URL.
specificationNoLayer 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_contextNoOptional business requirements (expected volumes, cost targets, ROI constraints). If provided, the quote includes a business case.
rejected_alternativesNoOptions already considered and ruled out. Prevents re-suggesting and builds the learning corpus.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
engineering_evaluationYes

TDQS

A4.7/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 entire burden of behavioral disclosure—and it delivers extensively. It states 'nothing is submitted or stored,' denies engineering-validation/certification/physical-truth/supplier-acceptance/fabrication authority, clarifies 'Its finding-penalty score is not engineering soundness,' and explains that reference_only comparisons are 'never a pass, failure, or blocker.' It also discloses failure-adjacent behaviors like 'classification is advisory, never blocks,' 'Undeclared interfaces are unchecked — nothing is inferred,' and 'never read HTTP success alone as proof that every field was understood.' This is exceptional disclosure for a tool with zero annotation coverage.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Every sentence is substantive and non-redundant, and the opener is a strong front-load ('Instant, synchronous engineering review of a physical requirement — nothing is submitted or stored'). However, the description is one dense, unbroken wall of text with no paragraph breaks or hierarchy, and operational imperatives like 'CHECK intake_classification first' and 'READ resolution_readiness, not quote_readiness' are buried mid-paragraph. The information earns its place, but the lack of structure measurably hurts an agent's ability to parse and retain it.

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 tool this complex—two intake modes, two readiness scores, assembly vs single-part handling, clarification plans, and authority boundaries—the description is remarkably complete. It covers what happens to the input, what the receipt contains (findings ranked blocker/warning/info, readiness scores, clarification_plan), what is denied, and the recommended downstream continuation ('next_call with the recommended exact MCP/REST continuation'). With an output schema present to back return-value details, nothing essential for correct invocation is missing.

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% with detailed per-field descriptions, so the baseline is 3. The description adds cross-cutting semantic value above the schema: the two intake modes (intent_only vs supplied specification), acceptance of 'legacy flat fields,' the uninterpreted_fields mechanism using 'bounded and privacy-safe RFC 6901 JSON Pointers,' and the specification.assembly shape for decomposed designs. It doesn't restate individual parameter docs but enriches how the whole parameter set should be interpreted, which is slightly better than the schema-only baseline.

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?

Opens with a specific verb and resource: 'Instant, synchronous engineering review of a physical requirement.' It enumerates concrete deterministic checks (material identification, rectangular beam deflection, bending stress, transverse shear, tolerance-vs-process, environment fit), so an agent can tell it apart from simulation, derivation, and validation siblings without opening their schemas. It also names its closest sibling—request_physical_solution—and explicitly contrasts the review role ('Accepts the same input...'), which removes ambiguity about where the tools diverge.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives explicit operational directives: 'CHECK intake_classification first', 'READ resolution_readiness, not quote_readiness', and 'a2a2p reviews one manufacturable part at a time' with capability_concept requests 'redirected to decomposition.' It specifies when to use the assembly path ('For a decomposed design, send specification.assembly'), warns that top-level part fields don't override declared parts, and closes the loop with continuation guidance ('re-review until quote_ready, then submit if a durable resolution is useful'). Alternative selection is effectively fully specified.

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

Try in Browser

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.

Resources