Price a building in light-gauge steel framing and start it with the nearest Gage fabricator.
Scored across 3 tools
The two quoting tools overlap in outcome but are clearly separated by input: quote_my_building takes a plain description while submit_design_for_quote takes structured geometry, and the descriptions explicitly tell the agent which to use. start_my_project is unmistakably distinct as the conversion step. Minor residual risk that an agent picks the quick quote when tighter geometry is available.
All three names follow a consistent snake_case verb_object pattern (quote_my_building, start_my_project, submit_design_for_quote). The 'my' possessive is a slight stylistic quirk but does not break the predictable convention.
Three tools form a tight, coherent funnel (quote via two paths, then start a project), so each earns its place. It sits at the low end of the ideal range and could feel thin if more lifecycle operations were expected.
The quote-to-project flow is covered, but the surface is entirely create-oriented with no read, list, or status operations (e.g. get quote by id, list/view projects, check project progress). Agents cannot retrieve or track prior work, creating notable dead ends.
Price a building in cold-formed steel framing from a plain description, through the Gage fabricator network: what it costs to have the frame fabricated and delivered, and which regional shop would build it.
Use this when someone has designed a house, ADU, cabin, garage, workshop or small commercial building (in this conversation or elsewhere) and asks what it would cost to build, how to get it built, or whether it can be framed in steel. For example, "how much to build this 1,900 sq ft one-storey gable house near 84032" -> total_sqft 1900, stories 1, roof_type "gable", zip "84032".
Only the size, storeys, roof and build-site ZIP are needed; ask the person for the ZIP if you do not have it. Anything else not given (ceiling heights, windows, doors, wall length, pitch, steel gauge) is filled with stated defaults and listed as assumptions. If you have exact walls and openings, submit_design_for_quote gives a tighter price.
The price is the steel frame package: framing steel, engineering and delivery. It is not the whole house (no foundation, finishes or labour on site). The fabricator is named by region until they take the job. When the person wants to go ahead, call start_my_project with the quote id.
| Name | Required | Description | Default |
|---|---|---|---|
| zip | Yes | 5-digit US ZIP code of the build site. | |
| doors | No | Number of doors to frame. Defaults to one per storey plus one. | |
| stories | Yes | Number of storeys, 1 to 4. | |
| windows | No | Number of windows. Defaults to about one per 120 sq ft. | |
| roof_type | Yes | Roof form. A-frames price as gable. | |
| roof_pitch | No | Roof pitch as "N:12". Defaults to 6:12, or 0:12 for a flat roof. | |
| total_sqft | Yes | Total floor area across all storeys, in square feet. | |
| project_type | Yes | residential for a house, cabin or home; adu for an accessory dwelling unit or backyard cottage; garage for a detached or attached garage, carport building or workshop; commercial for a shop, office or warehouse. | |
| ceiling_height_ft | No | Ceiling height in feet, the same on every storey. Defaults to 9. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Goes well beyond the annotations (which only declare openWorldHint=true and readOnlyHint=false) by disclosing what the price includes and excludes ('not the whole house - no foundation, finishes or labour on site'), how unspecified inputs are handled ('filled with stated defaults and listed as assumptions'), and that the fabricator is anonymised by region until it takes the job. These are material behavioral traits an agent cannot infer from structured fields.
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?
Front-loads the purpose, then usage, example, inputs, price scope, and next step in clearly ordered paragraphs. It is longer than typical, but almost every sentence carries non-redundant information; only the multi-clause opening sentence borders on dense.
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 9-parameter, no-output-schema tool, the description covers what is required vs defaulted, what the returned price represents, the assumption list, the anonymised fabricator, and the hand-off to start_my_project. An agent has everything needed to invoke it correctly and act on the result.
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?
With 100% schema coverage the baseline is 3, but the description adds genuine value: an end-to-end worked example mapping a plain-language request to total_sqft/stories/roof_type/zip, a statement of which fields are strictly needed, and an instruction to ask the user for the ZIP when missing. Defaults are also surfaced (e.g. ceiling height, windows, pitch), though most of these are already declared in the 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?
States a specific verb+resource ('price a building in cold-formed steel framing') and scopes it precisely to the steel frame package via the Gage network. It distinguishes itself from both siblings by name, so an agent can route between quote_my_building, submit_design_for_quote and start_my_project without opening any schema.
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?
Explicit trigger conditions are given ('when someone has designed a house, ADU, cabin, garage...and asks what it would cost'), along with a concrete example and an explicit alternative ('If you have exact walls and openings, submit_design_for_quote gives a tighter price'). It also names the follow-on tool and its required argument ('call start_my_project with the quote id').
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Start a real Gage project from a quote, so the person can get their building fabricated: Gage creates their project with the regional fabricator that priced it and emails them a private link to it. From that page they review the quote, talk to the fabricator and follow the frame to delivery. Nothing is charged by starting a project.
Only call this when the person has said they want to go ahead, and only with a name and email address they have given you for this. Ask them first: "Shall I send this to Gage so a fabricator can take it on? I'll need your name and email." Set person_agreed to true only after they say yes.
Use the quote_id from quote_my_building or submit_design_for_quote. The link goes to their email only; tell them to look for an email from Gage. How Gage handles their details: https://buildwithgage.com/privacy.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | The person's name, as they gave it. | |
| Yes | The person's email address, as they gave it. Their project link is sent here. | ||
| phone | No | Phone number, if they offered one. | |
| quote_id | Yes | The quote to build from, from quote_my_building or submit_design_for_quote. | |
| project_name | No | A short name for the project, e.g. "Lakeside cabin". | |
| person_agreed | Yes | True only once the person has agreed to send their details to Gage to start the project. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare destructiveHint=false and idempotentHint=true, but the description adds substantial context beyond them: nothing is charged, the link is emailed privately and goes only to the person's address, the person must consent first, and a privacy URL is provided. This is a rare case where a mutation tool discloses its side effects and limits well.
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?
Three paragraphs but front-loaded with the action and consequence first, then the consent gate, then the parameter sourcing. The consent script and privacy link justify their length, though the pacing is slightly conversational rather than tight.
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 6-parameter, non-read-only tool with no output schema, the description covers what happens after the call (project created, email sent), the consent requirement, the cost (free), and where the input comes from. Nothing an agent needs to invoke it correctly is missing.
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 100%, so the baseline is 3, but the description adds real meaning: it constrains which quote_id to pass (from quote_my_building or submit_design_for_quote), clarifies that name and email must be ones the person gave for this purpose, and explains what person_agreed semantically confirms. It stops short of clarifying phone or project_name, which remain schema-only.
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 a specific verb and resource ('Start a real Gage project from a quote') and explains the downstream effect: Gage creates the project with the regional fabricator and emails a private link. It also names the sibling tools that produce the required quote_id, so an agent can place it in the workflow without opening another schema.
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 gives explicit preconditions ('Only call this when the person has said they want to go ahead'), an exact consent script to say, and a rule for when to set person_agreed to true. The when-to-use and the gating condition are both spelled out rather than implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Submit a building design to Gage and get back a real, buildable cold-formed steel (CFS) framing quote from the Gage fabricator network.
Use this when you have generated or been given a floor plan or 3D house model and need to know what it costs to frame in steel, who would fabricate it, and how it breaks into panels.
Give it structured geometry (levels, walls as start/end points, openings, roof) plus the build site ZIP and project type. It reduces the model to the quoting engine's inputs, checks whether the design can actually be auto-panelized, and returns:
a structural feasibility flag,
an itemized quote (steel, transport, engineering, subtotal, confidence band, fabricator and lead time),
a downloadable preliminary panelization package (panel count, panel footage and totals; the panel-by-panel schedule goes to the Gage fabricator that takes the job).
It refuses rather than guesses. Geometry that is invalid or outside what the engine prices comes back as a structured error; a design that is legible but needs a structural decision (curved walls, a header over 12 ft, a cantilevered storey, tall walls) comes back with status "needs_human_review" and no price. A quote is only ever returned for a design that passed every check.
Pricing, tonnage and fabricator routing are computed by Gage API v1, not by this tool. Panelization output is preliminary and unstamped; stamped shop drawings are issued by the assigned fabricator after a quote is accepted.
| Name | Required | Description | Default |
|---|---|---|---|
| design | Yes | ||
| options | No | ||
| project | Yes |
| Name | Required | Description |
|---|---|---|
| meta | Yes | |
| quote | Yes | |
| review | Yes | |
| status | Yes | |
| compliance | Yes | |
| derivation | Yes | |
| next_steps | Yes | |
| feasibility | Yes | |
| panelization_package | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only declare the safety profile (not read-only, open-world, not idempotent, non-destructive); the description goes well beyond that. It discloses the refusal contract ("refuses rather than guesses"), the structured-error and needs_human_review statuses with concrete triggers (curved walls, headers over 12 ft, cantilevered storey), the fact that pricing/tonnage/routing come from Gage API v1 rather than this tool, and that panelization output is preliminary and unstamped. That is exactly the extra context an agent needs before committing a submission.
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 purpose is front-loaded in the first sentence, followed by usage, required inputs, return shape, and failure semantics in a logical order. It is longer than average but every block earns its place — the refusal and human-review paragraphs materially change how an agent should behave. No filler or repetition.
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?
An output schema exists, so the description is not obligated to detail return values, yet it still frames them at the right level (feasibility flag, itemized quote, panel package). Combined with the annotations covering safety and the schema covering field-level structure, an agent has everything needed to decide to call this tool and interpret its outcomes.
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?
Top-level schema description coverage is reported as 0% for the three parameters (design, project, options), so the description must carry weight — and it does, summarizing the required inputs as structured geometry (levels, walls as start/end points, openings, roof) plus build-site ZIP and project type. It does not cover defaults, units, or option flags such as stud_spacing_in or max_panel_length_ft, so it adds meaning without fully compensating for the coverage 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 opening sentence states a specific verb and resource: submit a building design and receive a real CFS framing quote from the Gage fabricator network. It also enumerates the outputs (feasibility flag, itemized quote, panelization package), so the agent knows exactly what the tool produces. It does not, however, distinguish this from the near-identically-named sibling quote_my_building, leaving that routing decision to inference.
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?
"Use this when you have generated or been given a floor plan or 3D house model and need to know what it costs to frame in steel" gives a clear triggering condition. The description also states when the tool will not produce a quote (invalid geometry, needs_human_review cases), which is useful negative guidance. It never names or excludes the sibling tools, so the when-to-use-vs-alternative dimension is only partially covered.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
quote_my_buildingstart_my_projectsubmit_design_for_quoteSteel takeoff, weight and gauge calculators plus RFQ, RFI, NCR and Bluebeam markup generators.
Instant parametric cost estimates for custom manufacturing: CNC, molding, sheet metal, 3DP, PCB.
Measure property from satellite imagery, price 24 trades, and install contractor quote widgets.
Manufacturing cost of CNC and sheet-metal parts from STEP or DXF: process plan, times, 10 lot sizes.
Add one secure layer between your agents and this server.
