Browse and book local tradespeople in the UK.
Scored across 7 tools
Most tools have distinct purposes: browse_trades (trade taxonomy), search_traders (find listings), get_trader (single profile), get_service_options (catalogue), plus discovery/OKF/page fetch utilities. Mild overlap exists between browse_trades and search_traders, and get_page_markdown can fetch pages that get_trader also covers, but these are distinguishable.
All names follow a consistent snake_case verb_noun pattern (browse_trades, get_trader, search_traders, read_open_knowledge_concept). Verbs vary appropriately (get/browse/search/read) while the convention stays uniform, making the set predictable.
Seven tools is well-scoped for a read-only trade directory/discovery server. Each tool covers a distinct facet (taxonomy, search, profile, services, discovery, knowledge, page rendering) without redundant padding.
The read-only discovery surface is largely complete: browse, search, retrieve profiles, service options, and knowledge/discovery endpoints. Contact/booking operations are intentionally excluded, so only minor gaps (e.g. structured trade detail or batch retrieval) remain.
List Tradehand's canonical UK trades. Instant quote is available before a trader is assigned.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| query | No | ||
| cursor | No |
| Name | Required | Description |
|---|---|---|
| data | Yes | |
| outcome | Yes | |
| blockers | Yes | |
| revision | No | |
| nextActions | Yes | |
| continuation | Yes | |
| missingFacts | Yes | |
| schemaVersion | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds only the domain note about instant quotes before trader assignment, and says nothing about pagination, result size, or filtering behavior despite the limit/cursor params.
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 core purpose is front-loaded in the first sentence, which is efficient. The second sentence about instant quotes is tangential and arguably muddies rather than supports the tool's function.
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?
An output schema exists, so return values need not be described, and annotations cover safety. Still, a browse/list tool with three undocumented optional params and an unexplained second sentence is only minimally complete.
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 description coverage is 0% across three parameters (limit, query, cursor), and the description mentions none of them. It fails to compensate for the coverage gap, leaving the agent to infer that query is a text filter and cursor enables paging.
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?
States a specific verb and resource ('List Tradehand's canonical UK trades'), which is clearer than most siblings (get_service_options, get_trader). It does not, however, differentiate itself from any related tool, since no sibling covers trades.
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 offers no when-to-use guidance, no prerequisites, and no alternatives (e.g., how this relates to get_service_options or search_traders). The second sentence discusses instant-quote availability rather than when to call this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Return the public agent discovery endpoints, content policy, and canonical URLs for Tradehand.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=false, so the safety profile is covered. The description adds the useful detail of what content is returned, but says nothing about caching, auth requirements, or freshness.
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?
A single well-formed sentence that front-loads the action and lists the returned artifacts. No filler or redundancy.
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 discovery tool with no output schema, the description adequately previews what comes back (endpoints, policy, canonical URLs). Slightly more detail on the return shape could help, but the essentials are present.
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 tool takes zero parameters, so the schema carries no semantic burden and there is nothing for the description to disambiguate. Baseline 4 applies.
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?
States a specific verb (Return) and enumerates the resource contents: public agent discovery endpoints, content policy, and canonical URLs. This clearly separates it from siblings like browse_trades or search_traders, though it does not explicitly name what it is not.
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?
There is no when-to-use or when-not-to-use guidance and no mention of alternatives. An agent must infer from the name alone that this is a metadata/discovery call rather than a search or browsing operation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fetch a public Tradehand website page as clean markdown for agent reading and summarisation.
| Name | Required | Description | Default |
|---|---|---|---|
| path | Yes | Public path on tradehand.com, for example /pricing or /for-trades. | / |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, openWorldHint=true, and destructiveHint=false, so the safety and access profile is covered. The description adds that only public pages are fetched and that output is normalized markdown, but says nothing about rate limits, error behavior for private paths, or page size.
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?
A single front-loaded sentence with no filler; the action and the resource come first. It is tight and appropriately sized for a one-parameter read tool.
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 simple read-only fetch with a fully described single parameter and no output schema, the description covers what an agent needs to call it correctly. Minor gaps around private-path behavior are not significant given the annotations already set expectations.
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?
With a single parameter at 100% schema description coverage, the schema already documents 'path' with an example. The description adds no syntax or format detail beyond what the schema provides, so baseline 3 applies.
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?
States a specific verb ('Fetch') and resource ('a public Tradehand website page') plus the transformation into 'clean markdown'. This is clearly distinguishable from siblings like get_trader or browse_trades, though it doesn't explicitly name an alternative.
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 phrase 'for agent reading and summarisation' implies the intended use, but there is no explicit when-to-use vs when-not guidance nor any named alternative among the sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Return the listing's actual catalogue services when one exists. Does not reserve a slot or claim bookability.
| Name | Required | Description | Default |
|---|---|---|---|
| publicReference | Yes |
| Name | Required | Description |
|---|---|---|
| data | Yes | |
| outcome | Yes | |
| blockers | Yes | |
| revision | No | |
| nextActions | Yes | |
| continuation | Yes | |
| missingFacts | Yes | |
| schemaVersion | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, so safety is covered by structured data. The description adds the extra nuance that the result confers no reservation or bookability, which is genuinely useful context, but says nothing about auth needs, rate limits, or the 'when one exists' empty-result case.
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 short sentences, front-loaded with the positive behavior and closed with the important caveat. No filler.
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?
An output schema exists, so return values needn't be described, and the 'when one exists' phrasing sensibly flags a possibly-absent result. However, the opaque 'publicReference' input and the lack of any indication of what a listing reference refers to leave a gap an agent must guess at.
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 description coverage is 0% for the single required parameter 'publicReference', and the description never explains what form that reference takes or where it comes from. With one undocumented parameter, the description fails to compensate for the coverage gap.
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?
States a specific verb and resource: it 'returns' the listing's 'actual catalogue services'. The conditional 'when one exists' qualifies the scope sensibly. It does not explicitly differentiate itself from siblings, though none of the listed siblings appear to overlap on catalogue services.
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?
Provides a negative guideline - 'Does not reserve a slot or claim bookability' - which usefully narrows expectations, but it does not say when to reach for this tool versus an alternative, nor name any sibling. Usage is implied rather than directed.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Return a public directory profile by listing slug. Instant quote remains available even when the listing has no purchasable catalogue. Does not expose phone, street address or coordinates.
| Name | Required | Description | Default |
|---|---|---|---|
| publicReference | Yes | Public directory listing slug from search_traders. |
| Name | Required | Description |
|---|---|---|
| data | Yes | |
| outcome | Yes | |
| blockers | Yes | |
| revision | No | |
| nextActions | Yes | |
| continuation | Yes | |
| missingFacts | Yes | |
| schemaVersion | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=true, so the safety profile is covered. The description adds real value beyond that: it discloses the privacy boundary (no phone, street address or coordinates) and an edge-case behavior (instant quote persists when no purchasable catalogue exists).
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?
Three short sentences, front-loaded with the core verb+resource and key. The privacy and catalogue sentences earn their place, though the "instant quote" clause is somewhat cryptic without more context.
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?
An output schema exists, so return-shape explanation is rightly omitted. The description covers keying, visibility limits, and the no-catalogue edge case; the only gap is the absence of explicit routing guidance to or from sibling lookup tools.
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 description coverage is 100% for the single publicReference parameter, so the schema already documents the slug and its origin in search_traders. The description's "by listing slug" adds no format or validation detail beyond that; baseline 3 applies.
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?
States a specific verb and resource ("Return a public directory profile") and the key used to fetch it ("by listing slug"), which implicitly separates it from search_traders and browse_trades. It stops short of naming a sibling explicitly, so the differentiation relies partly on the schema's reference to search_traders.
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?
Usage is only implied: you need a listing slug, which the schema says comes from search_traders. There is no explicit when-to-use/when-not, no stated prerequisites, and no named alternative for fetching trader data by other keys.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read one file of the Tradehand Open Knowledge Format bundle under /okf as raw markdown, YAML frontmatter intact. Start at /okf/index.md for the list of concepts.
| Name | Required | Description | Default |
|---|---|---|---|
| path | Yes | Bundle path under /okf, for example /okf/costs/eicr.md, /okf/costs/ or /okf/log.md. | /okf/index.md |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, openWorldHint=false, and destructiveHint=false. The description adds useful behavioral context by specifying the return format: raw markdown with YAML frontmatter intact, which is important since there is no output schema.
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 tightly written sentences that are front-loaded with the core action and scoping detail. Every clause earns its place without redundancy.
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 simple single-parameter read tool with annotations covering safety, the description gives the entry point and output format. It is nearly complete, though it does not clarify how directory-like paths in the schema examples (e.g., /okf/costs/) are handled.
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 description coverage is 100%, so the single path parameter is already well documented in the schema with examples. The description does not add meaning beyond what the schema provides, making the baseline score of 3 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 and resource: reading one file from the Tradehand Open Knowledge Format bundle under /okf as raw markdown with YAML frontmatter intact. It is clear and scoped, but it does not explicitly differentiate from sibling tools like get_page_markdown.
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 provides a clear starting point ('Start at /okf/index.md for the list of concepts'), which gives practical context for using the tool. However, it does not state when to choose this tool over alternatives or any exclusion conditions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Find current public Tradehand directory listings by trade and optional UK postcode or place. Returns claim state, listing-source freshness, accreditation names, and canonical profile URLs; it does not claim availability, expose mixed-source ratings, or contact anyone.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| trade | Yes | Trade name or directory slug, for example Electricians, plumber, or roofers. | |
| location | No | Optional UK town, city, or borough; do not combine with postcode. | |
| postcode | No | Optional full UK postcode, for example CO1 1AA. |
| Name | Required | Description |
|---|---|---|
| total | Yes | |
| trade | Yes | |
| status | Yes | |
| choices | No | Present when status is choose_place: the namesakes with their regions. Repeat the search with one location value. |
| listings | Yes | |
| returned | Yes | |
| truncated | Yes | |
| coverageNote | Yes | |
| resolvedArea | Yes | |
| requestedLocation | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish readOnly/openWorld/non-destructive, but the description adds real substance: it lists the returned fields (claim state, listing-source freshness, accreditation names, canonical profile URLs) and explicitly negates availability claims and mixed-source ratings. That is meaningful behavioral disclosure beyond the structured hints.
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?
A single dense sentence that front-loads the core action and scope before the exclusion clauses. No filler, nothing that could be trimmed without losing information.
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?
An output schema exists, so return formatting need not be explained, and the description is complete enough for correct invocation. The only gap is the absence of routing context relative to siblings, which is minor for a well-annotated read 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?
Schema description coverage is 75%, with trade/location/postcode well documented (including the 'do not combine with postcode' rule). The description restates the trade-plus-postcode/place filtering but adds no format or syntax detail beyond the schema; limit remains undescribed. Baseline 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?
States a specific verb (Find) and resource (public Tradehand directory listings) scoped by trade plus optional postcode/place. It's clearly distinct from a single-record fetch, but it never names the adjacent siblings (browse_trades, get_trader), so sibling differentiation is left to inference.
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 'does not' clauses (no availability claims, no mixed-source ratings, no contact) usefully bound the tool's remit, which implies its intended use. However there is no explicit when-to-use versus browse_trades or get_trader, nor any stated prerequisites, so guidance is only implied.
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.
search_traders3 fields changedOutput schema / properties / listings / items / properties / matchedTradeAdded value: +{
+ "description": "The trade searched for.",
+ "type": "string"
+}Output schema / properties / listings / items / properties / trade / descriptionAdded value: +"The listing's primary trade."Output schema / properties / listings / items / requiredPrevious value: -[
- "publicReference",
- "name",
- "trade",
- "location",
- "claimed",
- "accreditations",
- "sourceRegister",
- "sourceCheckedAt",
- "profileUrl"
-]New value: +[
+ "publicReference",
+ "name",
+ "trade",
+ "matchedTrade",
+ "location",
+ "claimed",
+ "accreditations",
+ "sourceRegister",
+ "sourceCheckedAt",
+ "profileUrl"
+]search_traders2 fields changedOutput schema / properties / choicesAdded value: +{
+ "description": "Present when status is choose_place: the namesakes with their regions. Repeat the search with one location value.",
+ "items": {
+ "additionalProperties": false,
+ "properties": {
+ "location": {
+ "type": "string"
+ },
+ "name": {
+ "type": "string"
+ },
+ "region": {
+ "type": [
+ "string",
+ "null"
+ ]
+ }
+ },
+ "required": [
+ "name",
+ "region",
+ "location"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+}Output schema / properties / status / enumPrevious value: -[
- "ok",
- "empty"
-]New value: +[
+ "ok",
+ "empty",
+ "choose_place"
+]read_okf_conceptread_open_knowledge_conceptbrowse_tradesget_agent_discoveryget_page_markdownget_service_optionsget_traderread_okf_conceptsearch_tradersWhich UK trades and local services are actually free right now. Live availability, not a directory.
Find, compare, and book local service businesses: live availability, prices, reviews, booking.
Search local businesses and book, order, quote or message any of them from one connection.
Find, get quotes from and book local service businesses on their own Square or Google calendar.
Add one secure layer between your agents and this server.
