OpenFab
Server Details
Experimental sandbox: custom-manufacturing quotes, lead time, DFM. Not a real supplier.
- Status
- Healthy
- Last Tested
- Transport
- Streamable HTTP
- URL
Glama MCP Gateway
Connect through Glama MCP Gateway for full control over tool access and complete visibility into every call.
Full call logging
Every tool call is logged with complete inputs and outputs, so you can debug issues and audit what your agents are doing.
Tool access control
Enable or disable individual tools per connector, so you decide what your agents can and cannot do.
Managed credentials
Glama handles OAuth flows, token storage, and automatic rotation, so credentials never expire on your clients.
Usage analytics
See which tools your agents call, how often, and when, so you can understand usage patterns and catch anomalies.
Tool Definition Quality
Average 2.8/5 across 5 of 5 tools scored. Lowest: 2/5.
Each tool addresses a distinct aspect of the manufacturing quoting workflow: capabilities discovery, lead time, manufacturability feedback, initial quote, and quote refinement. There is no functional overlap.
All tool names follow a consistent 'verb_noun' snake_case pattern (e.g., discover_capabilities, request_quote). Even dfm_feedback fits this pattern despite the acronym.
Five tools is an appropriate size for a focused manufacturing quote server. Each tool serves a clear purpose without excess or deficiency.
The toolset covers the core quoting workflow: capabilities discovery, lead time estimation, DFM feedback, and quote request/refinement. A minor missing feature is the ability to list or retrieve previously submitted quotes by token, but the refinement tool partially addresses this.
Available Tools
5 toolsdfm_feedbackCInspect
Indicative, rule-based manufacturability feedback.
| Name | Required | Description | Default |
|---|---|---|---|
| notes | No | ||
| finish | No | ||
| process | Yes | ||
| material | No | ||
| quantity | Yes | ||
| tolerance_mm | No | ||
| cad_reference | No | ||
| bounding_box_mm | No |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description states the feedback is 'indicative, rule-based', implying it is not definitive, but it does not disclose side effects, data persistence, or any behavioral details. Without annotations, this is insufficient for safe invocation.
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?
The description is extremely concise (a single phrase), but it sacrifices clarity and structure. It does not provide a clear breakdown of what the tool does.
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?
Given the tool has 8 parameters (6 optional), no output schema, and no annotations, the description is grossly incomplete. It fails to explain what the feedback looks like or how to use the parameters effectively.
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 0%, and the description adds no information about any of the 8 parameters. The meaning of 'process', 'quantity', 'material', etc., is not explained beyond their names and types.
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 'Indicative, rule-based manufacturability feedback', which indicates the tool provides feedback on manufacturability. However, it lacks specificity about what kind of feedback (e.g., scores, issues, recommendations) and does not differentiate from sibling tools like 'refine_quote' or 'discover_capabilities'.
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?
No guidance is given on when to use this tool versus its siblings. The description does not mention prerequisites, constraints, or scenarios where this tool is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
discover_capabilitiesAInspect
List supported manufacturing processes and what a quote requires.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, and the description only says 'list' which implies read-only, but does not explicitly state safety, idempotency, or other behavioral traits. Minimal disclosure for a tool with no behavioral cues.
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?
Single sentence of 8 words, front-loaded with verb, no wasted text. Extremely concise and well-structured.
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?
Tool has no input schema, no output schema, and no annotations. Description is minimal but sufficient for a simple listing tool. Could clarify what 'quote requires' means or hint at output format to improve completeness.
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?
No parameters exist, so description cannot add meaning beyond the schema. Rule states baseline 4 for 0 parameters, and description does not harm.
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?
Description clearly states the tool lists supported manufacturing processes and quote requirements, using specific verb 'list' and distinct resource. It distinguishes from sibling tools like dfm_feedback 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?
No guidance on when to use this tool vs alternatives. While siblings are named, there is no explicit when-to-use or when-not-to-use context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_lead_timeCInspect
Quick indicative lead time by process and quantity.
| Name | Required | Description | Default |
|---|---|---|---|
| process | Yes | ||
| quantity | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It mentions 'quick indicative' which implies the lead time is an estimate and not precise. However, it does not disclose other behavioral traits like whether it is read-only, requires authentication, or any side effects.
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?
The description is a single concise sentence that is front-loaded and to the point. However, it is slightly under-specified, missing details that could fit without clutter.
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?
Given no output schema, no parameter descriptions, and no annotations, the description is incomplete. It does not explain the return format, units of lead time, or how the tool fits with siblings. An agent would need additional context to use it effectively.
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 description coverage is 0%, and the description adds no extra meaning to the parameters beyond their names. It does not specify valid values for 'process' or constraints on 'quantity', leaving the agent unclear on how to set them correctly.
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 clearly indicates the tool retrieves lead time based on process and quantity. The verb 'get' and resource 'lead time' are specific. It distinguishes from sibling tools (dfm_feedback, discover_capabilities, etc.) which serve different purposes.
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 provides no guidance on when to use this tool versus alternatives. It does not specify prerequisites, context, or exclusions. An agent would not know if this is the best tool for the job among siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
refine_quoteCInspect
Refine a prior quote, referencing its quote_token.
| Name | Required | Description | Default |
|---|---|---|---|
| notes | No | ||
| token | Yes | ||
| finish | No | ||
| process | Yes | ||
| material | No | ||
| quantity | Yes | ||
| tolerance_mm | No | ||
| cad_reference | No | ||
| bounding_box_mm | No |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It states 'Refine' but does not disclose whether this is a partial update or full replacement, what happens to the original quote, or any side effects like recalculations. Critical behavioral traits are missing.
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?
The description is one short sentence, but given the tool's complexity (9 parameters, no schema descriptions, no output schema), it is severely underspecified. Conciseness should not sacrifice essential 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?
With 9 undocumented parameters, no output schema, and no annotations, the description provides almost no context. It fails to explain what refining entails, what parameters are needed, or what the tool returns. The tool is complex but the description is minimal.
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 description coverage is 0%, and the description adds no meaning to any of the 9 parameters. The only parameter implied is 'token' through the phrase 'quote_token'. Users get no help understanding 'process', 'finish', 'bounding_box_mm', etc.
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 clearly states 'Refine a prior quote' which indicates a modification operation on an existing quote. It distinguishes from sibling tools like 'request_quote' which creates new quotes. However, 'refine' is somewhat vague without further elaboration on what changes are possible.
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 mentions referencing a 'quote_token' implying a prerequisite of an existing quote. However, no explicit when-to-use or when-not-to-use guidance is given, nor are alternatives like 'request_quote' or 'dfm_feedback' compared.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
request_quoteBInspect
Get an indicative, non-binding quote for a custom manufactured part.
| Name | Required | Description | Default |
|---|---|---|---|
| notes | No | ||
| finish | No | ||
| process | Yes | ||
| material | No | ||
| quantity | Yes | ||
| tolerance_mm | No | ||
| cad_reference | No | ||
| bounding_box_mm | No |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description must compensate. It notes the quote is 'indicative, non-binding', which discloses some limitation, but lacks details on side effects, authentication needs, rate limits, or what happens on failure. Minimal disclosure for a tool that likely mutates state.
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?
A single sentence with no redundancy. It efficiently communicates the core action and context.
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?
Given 8 parameters, 2 required, no output schema, and a complex domain (custom manufacturing), the description is severely underspecified. It omits return format, parameter constraints, and prerequisites, making it insufficient for correct invocation.
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?
The description provides no information about any of the 8 parameters. With schema description coverage at 0%, the description fails to clarify how 'process','quantity','material','finish', etc. affect the quote. Agents must guess parameter roles from names alone.
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 clearly uses a specific verb ('Get') and resource ('quote') and adds context ('indicative, non-binding','custom manufactured part'), making the purpose unambiguous. It effectively distinguishes from siblings like 'refine_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?
The description implies this is for initial quote requests but does not explicitly state when to use vs alternatives (e.g., 'refine_quote' for adjustments). No usage conditions or exclusion criteria are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Claim this connector by publishing a /.well-known/glama.json file on your server's domain with the following structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"maintainers": [{ "email": "your-email@example.com" }]
}The email address must match the email associated with your Glama account. Once published, Glama will automatically detect and verify the file within a few minutes.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
Discussions
No comments yet. Be the first to start the discussion!