Baldwin Pergolas

Price a classic pergola kit

quote_classic_pergola

Price a classic Baldwin fiberglass pergola kit (freestanding, attached, or colonnade): pre-engineered and custom crafted, with all hardware, instructions, and a high-end factory paint finish. Returns the same price shown on the live 3D configurator at baldwinpergolas.com. Budgetary estimate, not a binding quote. Optional electrical, installation, shipping, footings, permits, and tax are quoted separately. Call get_pergola_guidance first. With attachment and approximate size, offer a starting estimate using stated defaults; continue discussing preferences afterward. Explain support-center versus overall roof dimensions. Present the exact returned configurator_url as a clickable text hyperlink to Baldwin website, or a button if supported. Do not automatically open or embed the configurator in a sidebar, modal, iframe, or in-chat portal. Introduce the available user controls.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "width_in": "<width_in>",
      "depth_in": "<depth_in>"
    },
    "name": "quote_classic_pergola"
  }
}

Input Schema

Name	Required	Description	Default
`beam`	No	Beam size. 2x8 is standard; 4x12 is a heavier profile.	2x8
`tail`	No	Rafter tail profile.	windsor
`color`	No	Paint color. "custom" requires color_hex.	white
`mount`	No	Mounting surface. Does not affect the kit price.	Concrete Footings
`config`	No	freestanding: independent structure; attached: ledger-mounted to a building; colonnade: single-row covered walkway.	freestanding
`ai_model`	No	Exact model only if actually known; otherwise omit. Do not infer it from the application.
`depth_in`	Yes	Depth in inches, column center-to-center (96–288). For attached, from column center to the house. For colonnade: rafter overhang per side in inches (24–48).
`sun_time`	No	Visualization hour in decimal 24-hour time; 17.55 means the supplied evening setting.
`width_in`	Yes	Width in inches, column center-to-center. Example: 216 for 18 feet.
`ai_client`	No	AI application when known, e.g. ChatGPT or Claude. Client-reported; do not guess.
`color_hex`	No	Six-digit hex color, required when color is "custom". Example: #2c3440.
`height_in`	No	Column height in inches. Columns come in 8/10/12 ft stock; pricing rounds up to the next stock length.
`column_qty`	No	Number of columns; omit for automatic. Freestanding requires an even count of at least 4.
`project_id`	No	The project_id returned by an earlier call in this conversation. Reuse it so the summary stays with the same project.
`project_use`	No	Generic stated purpose, e.g. church gathering area or family patio. No individual or organization names.
`centered_fan`	No	Set true when the customer wants a centered ceiling fan. Forces an even rafter count so the fan can mount between rafters.
`column_style`	No	Column diameter and shape. 10square (10-inch square) is the most popular.	10square
`project_type`	No	residential, commercial, institutional, or unknown. A church/school project is institutional, not a statement about personal beliefs.
`sun_animating`	No	Whether the sun visualization animates. False preserves a fixed lighting view.
`project_region`	No	Stated state/province/region, e.g. Nebraska. No street address or precise location.
`project_country`	No	Country of the project when stated or unambiguously established. No IP-based guesses.
`uplight_percent`	No	Uplight visualization brightness only; electrical is quoted separately.
`downlight_percent`	No	Downlight visualization brightness only; electrical is quoted separately.
`purlin_spacing_in`	No	Desired purlin spacing in inches on-center.
`rafter_spacing_in`	No	Desired rafter spacing in inches on-center.
`conversation_summary`	No	Factual project summary under 1,500 characters: stated goals, use, architecture, accessories, alternatives and open design questions. Distinguish requests from ideas discussed. Exclude names, contact details, exact addresses, sensitive personal facts and inferences about wealth or willingness to pay. Saved for later contact submission; not yet delivered to sales. Follow host disclosure rules.

Schema Changelog

Changes observed during successful MCP inspections.

Changed4 schema fields changedNov 11, 2026

addedInput schema / properties / downlight_percent

Added value: +{
+  "description": "Downlight visualization brightness only; electrical is quoted separately.",
+  "maximum": 100,
+  "minimum": 0,
+  "type": "number"
+}

addedInput schema / properties / sun_animating

Added value: +{
+  "description": "Whether the sun visualization animates. False preserves a fixed lighting view.",
+  "type": "boolean"
+}

addedInput schema / properties / sun_time

Added value: +{
+  "description": "Visualization hour in decimal 24-hour time; 17.55 means the supplied evening setting.",
+  "maximum": 24,
+  "minimum": 0,
+  "type": "number"
+}

addedInput schema / properties / uplight_percent

Added value: +{
+  "description": "Uplight visualization brightness only; electrical is quoted separately.",
+  "maximum": 100,
+  "minimum": 0,
+  "type": "number"
+}

First observedNov 11, 2026

TDQS

A4.3/5.0

Behavior4/5

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

Annotations already declare readOnlyHint=false, destructiveHint=false, idempotentHint=false, and openWorldHint=false. The description adds substantial context beyond that: the price comes from the live 3D configurator, it is a budgetary estimate rather than a binding quote, and electrical/installation/shipping/permits/tax are quoted separately. It also mandates how the returned URL should be presented and forbids embedding it. It does not discuss persistence of the conversation_summary or idempotency behavior explicitly.

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 front-loaded with purpose and return behavior, then caveats, workflow, and UI constraints. Given a 26-parameter tool with no output schema, the length is largely justified, but the final UI instructions ('Present the exact returned configurator_url... Do not automatically open... Introduce the available user controls') read as a grab-bag of interface rules rather than a tight purpose statement.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a complex pricing tool with no output schema and limited annotations, the description covers the essential: what is priced, what is returned (price and configurator_url), caveats, prerequisite guidance, and presentation constraints. It does not fully enumerate the return payload (e.g., project_id or breakdown details), but the schema and project_id description fill some of that gap.

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?

With 100% schema description coverage, the schema already documents all 26 parameters, so the baseline is 3. The description adds useful procedural meaning beyond the schema by instructing the agent to use stated defaults for an initial estimate and to explain support-center versus overall roof dimensions, which clarifies interpretation of width_in/depth_in in conversation.

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 opens with a specific verb and resource: 'Price a classic Baldwin fiberglass pergola kit (freestanding, attached, or colonnade).' The word 'classic' plus the explicit config list lets an agent distinguish this from siblings like quote_modern_classic_pergola and quote_curved_pergola without opening their schemas.

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

Usage Guidelines4/5

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

It gives an explicit prerequisite ('Call get_pergola_guidance first') and a concrete workflow: offer a starting estimate using stated defaults, then continue discussing preferences. It does not explicitly state when to choose this tool over the modern-classic or curved siblings, though 'classic' implicitly scopes it.

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

All Baldwin Pergolas tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?