Instant parametric cost estimates for custom manufacturing: CNC, molding, sheet metal, 3DP, PCB.
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.
Average 3.5/5 across 7 of 7 tools scored. Lowest: 2.4/5.
Each tool addresses a distinct aspect: discovery, single-part quotes, BOM estimation, process comparison, lead time, quote refinement, and DFM feedback. The slight overlap between request_quote and compare_processes is mitigated by their different purposes (single process vs. multi-process comparison).
Most tools follow a verb_noun pattern (compare_processes, request_quote, estimate_bom). dfm_feedback deviates because 'dfm' is not a verb, making it a minor inconsistency, but the overall naming remains readable and predictable.
Seven tools is well-scoped for a manufacturing estimation service. Each tool serves a distinct need with no redundancy, and the count is neither too sparse nor overwhelming for the domain.
The core workflow (discover capabilities, request quote, refine quote) is covered, along with BOM estimation and process comparison. However, there is no direct 'get_quote' tool to retrieve a previous estimate without refining it, which is a minor gap that can be worked around via refine_quote.
compare_processesAInspectCompare cost and lead time for one part across manufacturing processes.
Provide 2-8 process names and a quantity; returns per-process estimates sorted by total cost, plus a lowest-cost / shortest-lead-time note. Indicative and non-binding.
| Name | Required | Description | Default |
|---|---|---|---|
| finish | No | ||
| material | No | ||
| quantity | Yes | ||
| processes | Yes | ||
| tolerance_mm | No | ||
| bounding_box_mm | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It transparently explains that the tool returns per-process estimates, sorts them by total cost, and provides a lowest-cost/shortest-lead-time note. It also flags the outputs as 'indicative and non-binding,' which is a critical behavioral caveat about the reliability and finality of the results. No contradictions exist.
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 two crisp sentences with zero filler. It front-loads the core purpose and immediately gives actionable instructions and expected output. Every sentence adds value, making it highly efficient.
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, the description adequately explains the return format (per-process estimates sorted by total cost plus a note). However, it does not describe how optional parameters (material, finish, tolerance, bounding box) influence the estimates, which is a notable gap for a comparison tool where these inputs are likely important for accurate results. The description covers the core function but leaves feature-specific context under-explained.
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 schema has 0% description coverage, and the description only adds semantics for two of six parameters: 'processes' and 'quantity.' The optional parameters (finish, material, tolerance_mm, bounding_box_mm) are unexplained, leaving agents without guidance on how these affect the comparison. The description partially compensates but does not sufficiently cover the required schema gap.
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 the verb 'compare' with a specific resource (cost and lead time across manufacturing processes) and scope (one part). It also lists the output (per-process estimates sorted by total cost) and explicitly differentiates from sibling tools like get_lead_time, which likely covers a single process, and estimate_bom.
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?
It provides explicit usage instructions: 'Provide 2-8 process names and a quantity.' This tells the agent the necessary inputs and the range for the process list. It also implicitly distinguishes when to use (comparing multiple processes) and adds a caveat that it is 'indicative and non-binding,' guiding appropriate use. It lacks explicit alternatives, but the purpose makes the context clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
dfm_feedbackCInspectRule-based design-for-manufacturability feedback for a part specification.
| Name | Required | Description | Default |
|---|---|---|---|
| notes | No | ||
| finish | No | ||
| process | Yes | ||
| material | No | ||
| quantity | Yes | ||
| tolerance_mm | No | ||
| cad_reference | No | ||
| bounding_box_mm | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full responsibility for behavioral disclosure. It only mentions 'rule-based', which implies determinism, but does not state whether the tool is read-only, what inputs are essential, or what the feedback output looks like.
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 with no redundant wording. However, it is under-specified, but conciseness is about efficiency, and this sentence is efficient in conveying the core purpose.
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?
For a tool with eight parameters, no output schema, and no annotations, this description is severely incomplete. It provides only a high-level purpose and leaves the agent without enough information to reliably construct valid inputs or interpret the response.
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 parameter-level meaning. The eight parameters, including required 'process' and 'quantity', are left entirely unexplained, so the agent must rely on property 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 states that the tool provides design-for-manufacturability feedback for a part specification, which distinguishes it from sibling tools like estimate_bom or request_quote. While the verb 'feedback' is less specific than 'generate' or 'provide', the resource and focus are clear.
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 alternatives such as compare_processes or refine_quote. There are no context cues, exclusions, or prerequisite conditions, leaving the agent to infer usage from the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
discover_capabilitiesAInspectList supported manufacturing processes, materials, and the fields an estimate accepts.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of behavioral disclosure. It clearly indicates a read-only listing operation and specifies the output categories (processes, materials, fields). This is transparent enough for a zero-parameter tool, though it omits output format details.
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 sentence with a clear verb-first structure. Every word earns its place, and there is no redundant information or filler.
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's simplicity (no parameters, no output schema), the description adequately explains what it returns. It covers the main categories but does not elaborate on how the fields relate to the estimate process or any optional behavior. Still, it is complete enough for a discovery tool.
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 tool has zero parameters, so the schema covers everything. The description adds no parameter details, but the baseline for zero-parameter tools is 4 because there is nothing to clarify. It appropriately focuses on the output content.
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 the tool lists supported manufacturing processes, materials, and acceptable estimate fields. The verb 'List' is specific and the resource is well-defined, distinguishing it from sibling tools that focus on comparison, feedback, or estimation.
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 the tool is used to discover capabilities before estimating, but it does not explicitly state when to use it or mention alternatives. No reference to sibling tools like 'estimate_bom' or 'get_lead_time' is provided, so the agent has to infer context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
estimate_bomAInspectEstimate costs for a multi-part bill of materials in one call.
Each part: {process, quantity, material?, bounding_box_mm?, tolerance_mm?,
finish?}. Returns per-line estimates, a BOM total, and the longest lead
time. Indicative and non-binding. Max 50 lines.
| Name | Required | Description | Default |
|---|---|---|---|
| parts | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral disclosure burden. It states what the tool returns (per-line estimates, BOM total, longest lead time), the max 50-line limit, and the non-binding nature of results. It does not mention side effects, but as a cost estimation tool, the key behavioral aspects are covered.
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 two sentences, front-loaded with the primary purpose, then detailing part structure and outputs. Every sentence earns its place without redundancy.
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 a single-parameter schema and no output schema, the description compresses the essential contract: purpose, field structure, return summary, and constraints. It omits details like allowed process values or quantity units, but the estimation context makes these less critical 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 schema defines `parts` only as an array of objects with additionalProperties true, so the description is the sole source of field meaning. It lists expected fields (process, quantity, material?, bounding_box_mm?, tolerance_mm?, finish?) and marks optionality, adding significant value beyond the sparse schema.
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 the tool's purpose: 'Estimate costs for a multi-part bill of materials in one call,' specifying the verb (estimate), resource (multi-part bill of materials), and batch scope. This distinguishes it from siblings like get_lead_time or request_quote by emphasizing multi-part cost estimation.
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 usage context through 'Indicative and non-binding' and 'in one call,' suggesting this is for preliminary estimates rather than final quotes. However, it does not explicitly name alternatives or state when not to use the tool, so clear exclusions are missing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_lead_timeBInspectEstimated production lead time in days, by process and quantity.
| Name | Required | Description | Default |
|---|---|---|---|
| process | Yes | ||
| quantity | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry behavioral context. It states the output is an estimate in days, which is helpful, but it doesn't disclose any nuances like variability, data source, or return format. This is adequate for a simple query but lacks depth.
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 directly states the purpose. There is no redundant wording, and it is front-loaded with the core function.
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?
The tool has a simple signature with no output schema or annotations. The description covers the basic purpose but leaves out details like return value format, possible process values, and any edge cases. It is minimally viable but not fully complete.
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 mentions both parameters (process and quantity) but adds little beyond their names. It doesn't explain valid process values, quantity units, or any constraints. Since schema coverage is 0%, the description should compensate more but doesn't.
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 identifies the tool as providing estimated production lead time in days, scoped by process and quantity. This distinguishes it from sibling tools like compare_processes and estimate_bom, making the purpose unambiguous.
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 offers no guidance on when to use this tool versus alternatives, nor does it mention any prerequisites or exclusions. It only states the basic function, leaving the agent to infer usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
refine_quoteCInspectRefine a previous estimate (change quantity, material, tolerance, finish) by passing 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 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It implies a mutation (refine/change an existing quote) but does not state whether this modifies the original record, requires permissions, is reversible, or what side effects may occur. This is a significant gap for a tool that likely modifies prior estimates.
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, focused sentence that front-loads the core purpose and critical input (quote_token). There is no wasted wording, making it efficiently concise.
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?
The tool has 9 parameters, no annotations, and no output schema, yet the description offers only one sentence. It omits return behavior, success/failure conditions, error handling, or any details about how the refinement affects the original quote. This is grossly inadequate for a mutation tool of this complexity.
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%, so the description must compensate. It does explain that the token identifies the quote and lists some changeable fields (quantity, material, tolerance, finish), but it fails to clarify the required 'process' parameter or optional fields like 'cad_reference' and 'bounding_box_mm'. This partial coverage is insufficient for a 9-parameter tool.
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 the tool's purpose: 'Refine a previous estimate' with a specific mechanism ('by passing its quote_token'). It also lists the key modifiable fields (quantity, material, tolerance, finish), distinguishing it from sibling tools like request_quote (new quotes) and estimate_bom (BOM estimation).
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 provided on when to use this tool versus alternatives. The description does not mention prerequisites, exclusions, or mention sibling tools like request_quote for new quotes. The context of 'previous estimate' implies usage for refinements, but there is no explicit when/when-not guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
request_quoteBInspectGet an instant cost estimate for a custom manufactured part. Returns unit price, total, lead time, and assumptions. Indicative and non-binding.
| Name | Required | Description | Default |
|---|---|---|---|
| notes | No | ||
| finish | No | ||
| process | Yes | ||
| material | No | ||
| quantity | Yes | ||
| tolerance_mm | No | ||
| cad_reference | No | ||
| bounding_box_mm | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of behavioral disclosure. It adds transparency by noting that the estimate is 'instant' and 'indicative and non-binding,' which is useful context. However, it does not disclose whether the tool creates a request or has side effects, nor does it mention prerequisites or rate limits.
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 three concise sentences that front-load the core purpose, list outputs, and add an important caveat. Every sentence earns its place, with no redundancy or fluff.
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?
For a tool with eight parameters, no output schema, and no annotations, this description is too sparse. It omits how to specify the part geometry (e.g., CAD reference vs. bounding box), what 'assumptions' might include, and any error or qualification conditions. The tool is complex and would benefit from more detail.
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 does not explain any of the eight parameters. It adds no meaning beyond the raw schema fields, leaving the agent to guess the significance of parameters like bounding_box_mm, tolerance_mm, or cad_reference.
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 the tool's function as getting an instant cost estimate for a custom manufactured part, and lists specific outputs (unit price, total, lead time, assumptions). This distinguishes it from sibling tools like get_lead_time (which focuses only on lead time) and refine_quote (which implies a later step).
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 explicit guidance on when to use this tool versus alternatives such as estimate_bom or get_lead_time. It only implies the tool is for cost estimation, without stating prerequisites, exclusions, or why to choose it over siblings.
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.
No comments yet. Be the first to start the discussion!