Baldwin Pergolas

Price a modern classic pergola kit

quote_modern_classic_pergola

Price a modern classic Baldwin fiberglass pergola kit (four columns with an aluminum-look finish and hat trim): pre-engineered and custom crafted, with all hardware, instructions, and a high-end factory paint finish. The structure stays the same while the trim adjusts in three architecture steps: classic (Greco-Roman), modern classic, and modern. 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": {
      "width_in": "<width_in>",
      "depth_in": "<depth_in>"
    },
    "name": "quote_modern_classic_pergola"
  }
}

Input Schema

Name	Required	Description	Default
`color`	No	Paint color. "custom" is not currently priceable online for modern classic.	white
`dentils`	No	Include dentil molding. Adds $5 per dentil to the price.
`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.
`width_in`	Yes	Width in inches, column center-to-center.
`ai_client`	No	AI application when known, e.g. ChatGPT or Claude. Client-reported; do not guess.
`height_in`	No	Column height in inches.
`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.
`architecture`	No	Architectural style, set by trim only; the structure stays the same. classic is Greco-Roman, modern_classic is the middle step, modern is the most contemporary.	modern_classic
`project_type`	No	residential, commercial, institutional, or unknown. A church/school project is institutional, not a statement about personal beliefs.
`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_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.

First observedNov 11, 2026

TDQS

A3.9/5.0

Behavior4/5

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

With annotations present but sparse, the description adds substantial context the agent would otherwise lack: the result is a budgetary estimate rather than a binding quote, electrical/installation/shipping/footings/permits/tax are quoted separately, and a configurator_url is returned matching the live 3D configurator. It also discloses that the summary is saved for later contact submission but not yet delivered to sales. It does not address whether repeated calls create a new project (idempotentHint is false), which is a minor omission.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The purpose is front-loaded, but the runoff first sentence carries decorative boilerplate ('pre-engineered and custom crafted, with all hardware, instructions, and a high-end factory paint finish') that does not help tool selection. Purpose, output caveats, workflow, and UI-presentation policy are stacked into one block without separation, making the presentation rules easy to miss.

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 16-parameter pricing tool with no output schema, the definition covers return content (price plus configurator_url), estimate caveats, prerequisite tool, and how to present the link, which is most of what an agent needs. The main gap is persistence/idempotency behavior across repeated calls with the same project_id.

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 baseline would be 3, but the description adds meaning beyond the schema by explaining that architecture changes only the trim and not the structure, and by instructing the agent to explain support-center versus overall roof dimensions. These clarifications materially reduce misreporting of the width_in/depth_in center-to-center values.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The opening sentence names a specific verb and resource (price a modern classic Baldwin fiberglass pergola kit) and scopes it with the concrete feature set (four columns, aluminum-look finish, hat trim). However, it then says the tool covers classic, modern classic, and modern trim via the architecture parameter, which blurs the boundary against the sibling quote_classic_pergola and leaves the agent unsure why a separate entry point exists.

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 real workflow direction: call get_pergola_guidance first, offer a starting estimate using stated defaults once attachment and approximate size are known, then continue discussing preferences. It does not state when this tool should be preferred over quote_classic_pergola or quote_curved_pergola, which is the one guidance gap.

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?