Spark Pack

Is this job notifiable under Part P?

check_part_p

Read-onlyIdempotent

Answers whether domestic electrical work in England or Wales must be notified to building control under Part P of the Building Regulations, with the reason and what to do next (self-certify through a competent person scheme within 30 days, or tell building control before starting). England and Wales differ: in Wales kitchens and outdoor areas are still special locations. Returns notifiable (true or false), answer, reason, what_to_do, must_check and sources. Scotland and Northern Ireland return not_covered. Example: adding a socket in a kitchen in England: {"nation":"england","work":"add_to_or_alter_existing_circuit","locations":["kitchen"]}.

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": {
      "nation": "<nation>",
      "work": "<work>"
    },
    "name": "check_part_p"
  }
}

Input Schema

Name	Required	Description
`work`	Yes	The kind of work. Pick the most significant if the job has several parts (a new circuit outranks everything).
`trade`	No	Optional. The electrician's own business details (Nero Trade Profile v1). Used to prefill certificate contractor fields and to give a stable nero_trade_ref. Not stored by Spark Pack.
`nation`	Yes	Where the property is.
`building`	No	Defaults to dwelling.
`locations`	No	Where the work is. bath_or_shower_zone means within the zoned space around a bath or shower. Defaults to ["elsewhere"].
`registered_with_competent_person_scheme`	No	Whether the electrician is registered with a scheme such as NICEIC or NAPIT. Changes the next steps.

Schema Changelog

Changes observed during successful MCP inspections.

First observedNov 13, 2026

TDQS

A4.2/5.0

Behavior4/5

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

Annotations already cover read-only, idempotent, non-destructive, closed-world behavior, so the bar is lower; the description still adds real context by naming the returned fields (notifiable, answer, reason, what_to_do, must_check, sources) and disclosing the substantive compliance rule (self-certify via a competent person scheme within 30 days, or notify building control before starting). The England/Wales divergence on kitchens and outdoor areas is a behavioral detail an agent could not infer elsewhere.

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?

Front-loaded with the core question and jurisdiction, then next steps, then return fields, then a concrete example — a sensible ordering. It is dense and runs long for one paragraph, but no sentence is pure filler.

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 6-parameter tool with a nested object and no output schema, the description compensates by enumerating the return fields and their meaning, and by spelling out the downstream action. An agent has everything needed to decide whether to call it and how to interpret the result.

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?

With 100% schema description coverage and three enums, the schema already carries the parameter semantics, making 3 the baseline. The worked example (nation=england, work=add_to_or_alter_existing_circuit, locations=[kitchen]) does show how the parameters combine and illustrates the most-significant-work rule, but the optional nested `trade` object and `building` parameter are not addressed in the description at all.

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?

States a specific verb+resource+scope: whether domestic electrical work in England or Wales is notifiable under Part P, with the reason and next steps. Explicitly carves out Scotland and Northern Ireland as returning not_covered, so the jurisdictional boundary is unambiguous without opening the schema.

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?

Gives clear conditions for use (domestic electrical work, England/Wales) and states that Scotland/NI are out of scope with a defined return value, plus the difference in Welsh special locations. It does not point to a sibling such as check_certificate for the follow-on step, so it stops just short of explicit alternatives.

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

All Spark Pack 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.