Garage Doorman, Grimsby ON residential garage door repair: business facts, site search, quotes.
Scored across 4 tools
Each tool has a distinct role: search finds pages, fetch reads them, get_business_facts returns curated business information, and request_quote performs a real-world action. Even though search/fetch and get_business_facts both retrieve website content, the descriptions and explicit 'call this first' instruction keep boundaries clear.
The names are readable and imperative, but they mix bare verbs (fetch, search) with verb_noun phrases (get_business_facts, request_quote). The naming convention is not consistently applied across the four tools.
Four tools is a well-scoped set for this small-business domain. Search, fetch, facts, and quote request each cover a necessary function without redundancy or bloat.
The set covers the full apparent workflow: discovering business facts, searching and reading site content, and requesting contact from the business. No significant missing operation is apparent for this domain.
The full text of one page of the Garage Doorman website, as Markdown, with its canonical URL for citation. The id comes from search.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | A page id returned by search. |
| Name | Required | Description |
|---|---|---|
| id | Yes | |
| url | Yes | |
| text | Yes | |
| title | Yes | |
| metadata | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, openWorldHint, and idempotentHint, so the safety profile is covered. The description adds useful behavioral details beyond annotations: the response is Markdown text and includes a canonical URL for citation. This is meaningful context without contradicting the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that communicates the resource, output format, and id source without wasted words. It earns every part and remains easy to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a one-parameter read tool with rich annotations and an output schema, the description is complete. It explains what the tool returns, how the id is obtained, and cites the output behavior, leaving no essential gap for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already documents the single parameter with 100% coverage, and the description reinforces that the id comes from search. This is a standard baseline case where the schema carries the explanatory load; the description adds no additional semantic detail beyond source provenance.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource: retrieving the full text of one page from the Garage Doorman website as Markdown. It also mentions the canonical URL for citation, which helps distinguish this from sibling tools like search or get_business_facts. The title reinforces the read action clearly.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context that the id comes from search, implying this tool should be used after search returns a page id. It does not explicitly enumerate when not to use it or name alternatives, but the provenance guidance is enough to route an agent correctly.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
The published facts about Garage Doorman: what it does, the phone number, opening hours, the towns it serves, its services, and how it handles pricing. Every fact here also appears on the public website. Call this first.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and idempotentHint. The description adds that every fact is published on the public website, signaling that data is public, stable, and non-sensitive. This is useful behavioral context beyond the annotations, with no contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two compact sentences with no filler. The first sentence front-loads the resource and content scope; the second adds provenance and a clear usage instruction. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter, read-only, idempotent lookup, the description is complete: it states what data is returned, that it is publicly sourced, and how to sequence it relative to other tools. No output schema is necessary for this simple call.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters, so there is no parameter burden. The description still adds value by listing the semantic content categories an agent can expect, such as services, pricing, and service area.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the resource ('Garage Doorman') and enumerates the exact fact categories returned: what it does, phone number, opening hours, towns served, services, and pricing. It is easily distinguishable from siblings like fetch, search, and request_quote because it is specifically the business-facts lookup.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
'Call this first' is an explicit usage directive telling the agent to invoke this tool before alternatives. However, it does not explicitly state when not to use fetch, search, or request_quote, so some exclusion guidance is missing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Ask Garage Doorman to contact a homeowner about a garage door repair, a new door, an opener or a tune-up. This sends a REAL message to a real small business, so call it only when the person has clearly asked to be contacted by Garage Doorman and has given you their own name and their own phone number or email. Never guess or invent contact details. Plain words only, no links. One request per person per day. If it is urgent, give them the phone number instead: (905) 536-5369.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | The customer's own name. | |
| town | No | Town or postal code where the work is. | |
| No | The customer's email address. Give this or phone. | ||
| phone | No | The customer's phone number, ten digits. Give this or email. | |
| details | Yes | What they need, in the customer's own terms. Plain text, no links, 800 characters at most. | |
| service | No | What they need: repair = a repair; new-door = a new garage door; opener = opener work; tune-up = a tune-up or service; other = something else. | |
| preferred_time | No | When they would like to be contacted or visited, if they said. | |
| consent_to_contact | Yes | Must be true: the customer has asked to be contacted by this business about this request. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only indicate readOnlyHint=false curved, but the description discloses the critical real-world side effect: it sends a real message to a small business. It also warns against guessing/inventing details, adds a per-day limit, and provides an urgent fallback, going well beyond the structured annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is four sentences long, front-loaded with the core purpose and then packed with necessary guardrails. No unnecessary fluff; each sentence adds crucial operational context (real message, consent, no inventions, one per day, urgent alternative).
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 8 parameters, no output schema, and limited annotations, the description covers all essential operational requirements: when to call, who to call for, what to include, what not to do, rate limit, and urgent-case fallback. There are no significant gaps that would leave an agent unsure how to invoke it safely.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% (all 8 params documented), so the baseline is 3. The description adds extra semantic constraints not fully captured by the schema, such as requiring the customer's own contact detailschers, emphasizing 'Really sent' and the urgency fallback, which informs how parameters like phone and consent_to_contact should be valued. It does not repeat every param detail but reinforces the key correctness constraints.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action: asking Garage Doorman to contact a homeowner about specific services (repair, new door, opener, tune-up). It distinguishes itself from sibling tools like search and fetch by emphasizing that it sends a REAL message to a real small business, making the tool's purpose unmistakable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit when-to-use conditions: only when the person has clearly asked to be contacted and has provided their own contact details. It also gives clear exclusions, such as urgent situations where the phone number should be given instead, plus rate limiting (one request per person per day).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Keyword search over the pages of the Garage Doorman website. Returns page ids, titles and canonical URLs. Use fetch with an id to read a page.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | Plain words to look for, for example "broken spring" or "vinyl plank basement". |
| Name | Required | Description |
|---|---|---|
| results | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and idempotentHint=true, so the safety profile is covered. The description adds that the search covers the website's pages and returns specific fields, which is useful context but doesn't go into pagination or result limits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two short sentences with no fluff: it states the scope, the return fields, and gives the next step (fetch). The most relevant info (search scope) is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter read-only search tool with an output schema, the description covers the essential purpose and provides a clear handoff to fetch. It doesn't mention things like result ordering or error handling, but these are likely in the output schema and not required for a simple search tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema fully documents the 'query' parameter with examples, and the description adds no further parameter semantics. Given 100% schema coverage, a baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('search') and resource ('pages of the Garage Doorman website'), and lists the returned fields (page ids, titles, canonical URLs). This clearly distinguishes it from siblings like fetch (which reads a page by id) and request_quote.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly instructs to 'Use fetch with an id to read a page,' providing a clear handoff from search to fetch. However, it doesn't explicitly state when not to use search (e.g., when you already have an id), so the guidance is good but not exhaustive.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
fetchget_business_factsrequest_quotesearchCommercial Garage Doorman, Hamilton area commercial door service: business facts and site search.
905 Trades, Hamilton ON residential trades referral network: facts, site search, quote requests.
Referral Flooring, Hamilton ON flooring installer: business facts, site search, quote requests.
Search thousands of verified US local service providers across 10 home-services trades, including crawl space repair, floor coating, radon mitigation, commercial electrical, and laundry services. Returns ratings, services, pricing, descriptions, and profile links. Every result passes a completeness gate, so listings are never half-empty.
Add one secure layer between your agents and this server.
