Skip to main content
Glama

Nero Reviews: verified job reviews for trades

Log a finished job and get the review link to send

job_done

Records a finished job, whether the customer seemed happy or not (asking every customer, not only happy ones, keeps the reviews fair), for example when the trade says "job done for Mrs Patel". Returns a one-time review link, a ready-to-send neutral message (message_to_send), and WhatsApp and SMS share links. Nero sends nothing: the trade sends the message to the customer, ideally the same day. The customer taps 1 to 5 stars and can add a sentence. Calling it twice for the same customer and job within 24 hours returns the same link. Rules enforced here: there is no option to ask only happy customers (that is review gating, banned by UK law), and a custom message_intro is refused if it asks for a particular rating, steers unhappy customers elsewhere, or offers any reward. Limit 30 jobs a day per business.

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_key": "<trade_key>",
      "customer_name": "<customer_name>",
      "job_summary": "<job_summary>"
    },
    "name": "job_done"
  }
}

Input Schema

NameRequiredDescriptionDefault
trade_keyYesThe trade_key that register_trade returned for this business (starts with nrk_).
finished_onNoDate the job finished, YYYY-MM-DD. Defaults to today. Must be within the last 90 days.
job_summaryYesA few words on the job, shown with the review, for example "Consumer unit swap" or "Boiler service". No addresses or phone numbers.
customer_nameYesHow the trade refers to the customer, for example "Mrs Patel" or "John Smith". Used in the message. Publicly only the first word and an initial show ("Mrs P."), and the customer can change it.
message_introNoOptional first sentence of the message in the trade's own words, for example "Hi Mrs Patel, thanks for having me round today." The link and a neutral ask are always added after it.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.6/5.0
Behavior5/5

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

Beyond the annotations, the description discloses the return payload (one-time link, ready-to-send message, WhatsApp/SMS share links), that no message is sent automatically, the customer rating flow, a 24-hour idempotency window for the link, multiple enforced business rules (no review gating, message_intro restrictions), and a daily rate limit. This is rich behavioral context that an agent would not infer from annotations.

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

Conciseness4/5

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

The description is front-loaded with the core action and is logically organized: purpose, outputs, sending responsibility, customer experience, idempotency, rules, limit. It is slightly dense but every sentence provides useful information, with no obvious filler or redundancy.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a write tool with no output schema, the description covers what is returned, what side effects occur (none sent automatically), idempotency behavior, validation rules, and rate limits. It is complete enough that an agent can invoke it correctly without additional documentation.

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%, so the baseline is 3, but the description adds meaningful constraints on the message_intro parameter: it is refused if it asks for a specific rating, steers unhappy customers elsewhere, or offers rewards. That goes beyond the schema's description and helps an agent avoid invalid inputs, though other parameters are left to 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?

The description states a specific verb and resource: it records a finished job and returns a review link. It names the exact scenario ('job done for Mrs Patel') and distinguishes the tool from sending mechanisms by clarifying 'Nero sends nothing: the trade sends the message.' An agent can tell this is the job-completion logging tool, not a review reply or dispute tool.

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?

The description gives a clear usage context ('when the trade says job done for Mrs Patel') and explains the tool's role in the workflow: generating a link for the trade to send themselves. It does not explicitly compare to alternatives or state when not to use it, but the sibling tools cover different operations, so the guidance is sufficient without naming a competing tool.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.