Baldwin Pergolas

Get a contact link for custom or commercial projects

create_contact_link

Get the right contact link for projects the configurators cannot handle. Use audience "homeowner" for custom projects outside the configurators (the contact form; Michael Hurlburt phones within 24 hours, except on weekends). Use audience "professional" for designers, architects, engineers, builders, specifiers, and contractors (the commercial projects questionnaire). Pass a short conversation_summary so the Baldwin team knows what was discussed.

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": {
      "audience": "<audience>"
    },
    "name": "create_contact_link"
  }
}

Input Schema

Name	Required	Description
`ai_model`	No	Exact model only if actually known; otherwise omit. Do not infer it from the application.
`audience`	Yes	homeowner for custom projects outside the configurators; professional for designers, architects, engineers, builders, specifiers, and contractors.
`ai_client`	No	AI application when known, e.g. ChatGPT or Claude. Client-reported; do not guess.
`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.
`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.
`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.5/5.0

Behavior4/5

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

Goes well past the annotations by disclosing the downstream workflow — a phone callback within 24 hours on weekdays for homeowners versus a questionnaire for professionals — and the schema notes the summary is stored but not yet delivered. The notable gap is that idempotentHint=false is never reflected in the description: nothing warns that repeat calls yield additional links or duplicate saved summaries.

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?

Four sentences, front-loaded with the scope constraint, then the two audience branches, then the summary instruction — no filler. Minor overlap with the audience enum text in the schema is the only waste.

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?

With nine parameters, no output schema and a mid-complexity workflow, the description covers what the tool produces and what happens to the data. It stops short of describing the link's form or lifetime, and it omits any repeat-call/idempotency guidance, which are the two things an agent could still get wrong.

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 is 3, but the description earns above baseline by explaining the routing consequence of the audience value rather than merely restating the enum, and by stating the purpose of conversation_summary ("so the Baldwin team knows what was discussed"). The remaining seven parameters are left entirely to the schema.

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?

"Get the right contact link for projects the configurators cannot handle" names a specific verb and resource and immediately scopes it away from the quoting/configurator siblings. The audience split (homeowner → contact form, professional → commercial questionnaire) tells an agent exactly which artifact it is producing.

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

Usage Guidelines5/5

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

States the trigger condition (projects the configurators cannot handle) and gives explicit when-to-use-which routing for both enum values, including the exact destination each one reaches. An agent can select the right audience without consulting any other source.

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?