Agentic Fabrication Network (AFN)

Network capabilities

get_network_capabilities

The LIVE catalog of what the fabrication network can do RIGHT NOW — no quote needed. Returns the services ledger (tapping, inserts, welding, bending, finishes… with each shop's own size/material/thickness windows), the network's sheet gauge ladder, the stocked hardware combinations (species x thread) with stocked lengths and shop counts — the most-stocked length is the steering default for an unspecified length — the finish options with their stocked color menus, and per-process manufacturability rules. This is live state, not a spec sheet: it changes as connectors join, leave, or have capability branches toggled, so call it fresh when the user asks what's possible (materials, gauges, hardware, colors, services) rather than answering from memory.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`process`	No	Advisory scope ("sheetmetal") — v1 returns the whole catalog either way; filter what you relay

TDQS

A4.6/5.0

Behavior5/5

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

With no annotations, the description carries the full behavioral burden, and it pays off: it discloses that this is live state that changes as connectors join/leave or capability branches toggle, that the process parameter is advisory in v1, and that unspecified lengths default to the most-stocked length. These are non-obvious behaviors that meaningfully affect invocation and interpretation.

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 a dense, front-loaded paragraph that communicates important scoping and behavioral details without irrelevant filler. It is longer than strictly necessary, but the detail is substantive and helps the agent understand a complex, information-rich tool.

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?

Given the tool has only one optional parameter and no output schema, the description covers the return surface well: services per shop, size/material/thickness windows, gauge ladder, stocked hardware combinations, finish color menus, and manufacturability rules. It also covers dynamic behavior and usage context, so an agent has enough to invoke and interpret results correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The single parameter is 100% covered by the schema, which already states it is advisory and that v1 returns the whole catalog either way. The description reinforces this but does not add new parameter-level meaning beyond the schema.

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 names a specific resource (the live fabrication network capability catalog) and a clear verb (returns/retrieves), with an explicit contrast to quote tools. It enumerates the major content areas (services ledger, gauge ladder, hardware combos, finishes, manufacturability rules), making it easy to distinguish from get_fabrication_quote and get_material_guide.

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?

The description explicitly states when to call: whenever the user asks what's possible in materials, gauges, hardware, colors, or services, and not from memory. It also signals a key exclusion—'no quote needed'—implying that for actual quotations the user should use the quote tools. This is strong, actionable guidance.

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

All Agentic Fabrication Network (AFN) 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

A4.4/5.0

Disambiguation5/5

Each tool targets a distinct action in the fabrication workflow: quoting, refining, checkout, order status, reviews, etc. Even similar concepts like get_fabrication_quote and refine_quote are clearly separated by purpose (initial quote vs. modifying an existing one). Internal tools like poll_quote are explicitly marked and never confused with user-facing actions.

Naming Consistency5/5

All tool names follow a consistent verb_noun pattern in snake_case (create_checkout, get_fabrication_quote, refine_quote, etc.). The verbs are specific and predictable (create, get, list, refine, reply), making the API easy to navigate.

Tool Count5/5

With 10 tools, the server provides a focused but complete set for its purpose—ordering and managing physical fabrications. No tool seems superfluous, and each covers a necessary step in the user journey. This is within the ideal range of 3-15 tools.

Completeness4/5

The tool surface covers the full lifecycle: quoting, refining, checkout, order tracking, reviews, and vendor communication. Minor gaps exist (e.g., no explicit cancel or return flow), but these are likely handled outside the MCP or via the hosted platform. The main workflows are all supported without dead ends.

Resources

Need Help?