Tradehand

Search public trader listings

search_traders

Read-only

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.

Input Schema

TableJSON Schema

Name	Required	Description
`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.

Output Schema

TableJSON Schema

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

Schema Changelog

Changes observed during successful MCP inspections.

Changed3 schema fields changedOct 13, 2026

addedOutput schema / properties / listings / items / properties / matchedTrade

Added value: +{
+  "description": "The trade searched for.",
+  "type": "string"
+}

addedOutput schema / properties / listings / items / properties / trade / description
```
Added value: +"The listing's primary trade."
```

changedOutput schema / properties / listings / items / required

Previous value: -[
-  "publicReference",
-  "name",
-  "trade",
-  "location",
-  "claimed",
-  "accreditations",
-  "sourceRegister",
-  "sourceCheckedAt",
-  "profileUrl"
-]New value: +[
+  "publicReference",
+  "name",
+  "trade",
+  "matchedTrade",
+  "location",
+  "claimed",
+  "accreditations",
+  "sourceRegister",
+  "sourceCheckedAt",
+  "profileUrl"
+]

Changed2 schema fields changedOct 8, 2026

addedOutput schema / properties / choices

Added 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"
+}

changedOutput schema / properties / status / enum

Previous value: -[
-  "ok",
-  "empty"
-]New value: +[
+  "ok",
+  "empty",
+  "choose_place"
+]

First observedSep 29, 2026

TDQS

A3.8/5.0

Behavior4/5

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.

Conciseness5/5

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.

Completeness4/5

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.

Parameters3/5

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.

Purpose4/5

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.

Usage Guidelines3/5

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.

All Tradehand 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.