Skip to main content
Glama
Sign In

Site Pack

by io.github.Nero-Engine
OverviewDiscussionsAdmin

Check the builder's business details

trade_profile
Read-onlyIdempotent

Checks the builder's own business details (Nero Trade Profile v1: trading name, Companies House number, trade body or scheme and membership number such as FMB or TrustMark, postcode, contact) and returns them cleaned, with a stable nero_trade_ref computed from the scheme membership or company number. The same object, given as trade to the other tools, prefills their answers. Site Pack stores nothing. The same profile and reference can later be used to sign the business into Nero Work, the agent job exchange for trades.

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": {
      "trade": "<trade>"
    },
    "name": "trade_profile"
  }
}

Input Schema

NameRequiredDescriptionDefault
tradeYesOptional. The builder's own business details (Nero Trade Profile v1). Used to prefill the contractor details in notices and CDM answers and to give a stable nero_trade_ref. Not stored by Site Pack.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

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, non-destructive and closed-world, so the safety profile is covered. The description adds genuinely new behaviour beyond that: outputs are \"cleaned\" and carry a derived, stable `nero_trade_ref` computed from scheme membership or company number, which explains why repeat calls are idempotent and what governs the reference value.

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

Conciseness3/5

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

The core is front-loaded and dense, but the closing sentence about signing into \"Nero Work, the agent job exchange for trades\" is promotional and does not aid tool selection. \"Site Pack stores nothing\" is also duplicated in the schema description, so some content does not earn its place.

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 a single required nested parameter and no output schema, the description carries the burden of describing the return value, which it does (cleaned details plus a stable `nero_trade_ref`) and it clarifies persistence. It is nearly complete; only the exact shape of the cleaned output and reference format are left implicit.

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% and the nested `trade` object documents each field, so the baseline is 3. The description goes beyond the schema by revealing which fields drive the reference (scheme membership or company number), telling an agent which inputs actually matter for the derived identifier.

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?

The description names a specific verb and resource (\"checks the builder's own business details\") and enumerates the exact fields covered (trading name, Companies House number, scheme membership number, postcode, contact). It also states the transformation performed (cleaning plus computing a stable `nero_trade_ref`), which cleanly separates it from the sibling compliance-check tools that take a `trade` object as input.

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?

It establishes the workflow relationship explicitly: \"The same object, given as `trade` to the other tools, prefills their answers,\" which tells an agent this is the profile-normalisation step whose output feeds the other tools. What is missing is any explicit exclusion or precondition (e.g. when not to call it, or whether it must precede the other checks), so it lands below a 5.

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

All Site Pack toolsInspect
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