Baldwin Pergolas

Price a curved pergola kit

quote_curved_pergola

Price a curved Baldwin fiberglass pergola kit (arc-based geometry): 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. 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": {
      "radius_ft": "<radius_ft>",
      "arc_deg": "<arc_deg>",
      "depth_ft": "<depth_ft>"
    },
    "name": "quote_curved_pergola"
  }
}

Input Schema

Name	Required	Description	Default
`tail`	No	Rafter tail profile.	windsor
`color`	No	Paint color.	white
`mount`	No	Mounting surface. Does not affect the kit price.	Concrete Footings
`arc_deg`	Yes	Arc angle in degrees. 360 is a full circle.
`ai_model`	No	Exact model only if actually known; otherwise omit. Do not infer it from the application.
`depth_ft`	Yes	Depth in feet, front row to back row. Use 0 for a curved colonnade.
`ai_client`	No	AI application when known, e.g. ChatGPT or Claude. Client-reported; do not guess.
`back_cols`	No	Back row column count. Use 0 for a curved colonnade.
`radius_ft`	Yes	Inner radius of the arc in feet.
`front_cols`	No	Front row column count.
`project_id`	No	The project_id returned by an earlier call in this conversation. Reuse it so the summary stays with the same project.
`bearing_deg`	No	Compass bearing in degrees (0 = north). Affects sun simulation only, not price.
`project_use`	No	Generic stated purpose, e.g. church gathering area or family patio. No individual or organization names.
`column_style`	No	Column diameter and shape.	10square
`project_type`	No	residential, commercial, institutional, or unknown. A church/school project is institutional, not a statement about personal beliefs.
`col_height_ft`	No	Column height in feet. Stock comes in 8/10/12 ft; pricing rounds up.
`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.
`purlin_spacing_ft`	No	Desired purlin spacing in feet on-center.
`rafter_spacing_ft`	No	Desired rafter spacing in feet 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.

First observedNov 11, 2026

TDQS

A4.6/5.0

Behavior5/5

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

Goes well beyond the annotations: it declares the result is a budgetary estimate and not a binding quote, that optional electrical, installation, shipping, footings, permits, and tax are quoted separately, and that the returned price matches the live 3D configurator. With no output schema, it also carries the return-value burden by naming configurator_url and specifying exactly how it must be presented (hyperlink/button, never embedded in a modal, iframe, or sidebar).

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?

Front-loads purpose and caveats before workflow and presentation rules, and every sentence carries an instruction. It is dense rather than bloated, though the presentation directives (hyperlink vs button, no iframe/sidebar) add length that could be tightened.

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?

For a 21-parameter pricing tool with no output schema, the definition covers what is priced, what is excluded, the estimate's non-binding status, the return artifact (configurator_url), the prerequisite tool, and post-call conversation behavior. An agent has everything needed to call it and to interpret the result correctly.

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?

Schema coverage is 100%, so the schema already documents all 21 parameters and a baseline of 3 would be defensible. The description adds genuine meaning by instructing use of stated defaults for a starting estimate and by telling the agent to explain support-center versus overall roof dimensions, which clarifies how radius/depth inputs are interpreted.

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?

States a specific verb (Price) and a precisely scoped resource: a curved Baldwin fiberglass pergola kit with arc-based geometry. The 'curved'/'arc-based' framing cleanly separates it from the straight-kit siblings quote_classic_pergola, quote_modern_classic_pergola, and quote_lattice_panel without needing to name them.

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?

Gives an explicit prerequisite ('Call get_pergola_guidance first') and a clear workflow: offer a starting estimate using stated defaults when attachment and approximate size are known, then continue discussing preferences. It does not explicitly state exclusions (e.g., 'do not use for straight pergolas'), but the curved/arc scoping makes the boundary unambiguous in practice.

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?