GroundQuote

Price a fence from a contractor's own rates

get_fence_estimate

Read-onlyIdempotent

Returns a price range for a fence from one GroundQuote contractor's published per-foot rates, gates and removal fee. Nothing is sent to the contractor. If the material/style/height is not offered, returns that contractor's options. Tell the homeowner it is an estimate until the contractor measures on site.

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": {
      "contractor_id": "<contractor_id>",
      "material": "<material>",
      "linear_feet": "<linear_feet>"
    },
    "name": "get_fence_estimate"
  }
}

Input Schema

Name	Required	Description
`style`	No	Style from the contractor's catalog (e.g. "Privacy"). Optional if they offer only one.
`height`	No	Height, e.g. "6 ft" or 6. Optional if only one is offered.
`material`	Yes	Material, from the contractor's catalog (e.g. "Wood", "Vinyl")
`linear_feet`	Yes	Total fence length in feet. Ask the homeowner; it is their estimate.
`double_gates`	No
`single_gates`	No
`contractor_id`	Yes	contractor_id from find_fence_contractors (instant_quote group)
`remove_old_fence`	No	Tear out and haul away an existing fence

Schema Changelog

Changes observed during successful MCP inspections.

AddedNov 5, 2026

TDQS

A4.2/5.0

Behavior4/5

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

Annotations already declare readOnlyHint, idempotentHint and openWorldHint=false, so the safety profile is covered; the description still adds genuinely new behavior: no outreach to the contractor, a documented alternate return path when the requested configuration is unavailable, and a required caveat about estimate status. It stops short of describing currency, range width, or what the gates/removal surcharges look like in the response.

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

Conciseness5/5

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

Three short sentences, front-loaded with what is returned and priced, then the fallback path, then the user-facing caveat. No filler and nothing repeated from the title or annotations.

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 an 8-parameter, no-output-schema tool, the description does the necessary work: it defines the returned value (price range), the alternate return shape, and the conversational obligation to the homeowner. Currency/units and the composition of the range are left unstated, but nothing blocks a correct call.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 75%, so the schema carries most parameter meaning; the description only links 'gates and removal fee' to the gate/removal parameters. The five undocumented fields (single_gates, double_gates, remove_old_fence) get no extra guidance in the prose, and the optional nature of style/height is already in 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?

States a specific verb and resource ('Returns a price range for a fence') plus the exact source of truth ('one GroundQuote contractor's published per-foot rates, gates and removal fee'). An agent can immediately distinguish this from set_fence_pricing (writes rates) and send_quote_request (contacts the contractor) without opening a schema.

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?

'Nothing is sent to the contractor' and the fallback rule for unoffered material/style/height clearly frame this as a pre-quote, self-serve estimate step. The prerequisite lookup (find_fence_contractors) is only conveyed through the contractor_id schema description rather than the prose, so the when-to-use chain is implied rather than spelled out.

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

All GroundQuote 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?