Decision-only MCP for household water problems with governed, structured next-action guidance.
Scored across 3 tools
describe_water_capability (metadata/capability description), get_water_decision (decision support output), and preflight_water_decision (scope/input validation) target distinct phases, and the descriptions reinforce the distinction. get_water_decision and preflight_water_decision could be mildly confused in ordering, but boundaries are reasonably clear.
All three names use consistent snake_case verb_noun form with a shared 'water' domain token. The noun varies (water_capability vs water_decision) but the pattern remains predictable.
Three tools is thin for a decision-support surface, leaving little room for exploring options or inputs. It is defensible for a deliberately narrow, read-only advisory scope, but sits at the borderline of under-scoped.
The describe/get/preflight triad covers the intended read-only lifecycle, and the explicit absence of contact/book/purchase tools appears intentional. However, there is no way to enumerate decision options or inputs beyond a single preflight check, leaving the surface minimal.
Describe Belanar public household-water decision capability. Read-only.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It does disclose 'Read-only', which is a useful trait, but nothing about whether it requires auth, whether results are static or dynamic, latency, or what form the capability description takes.
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 action and operator trait. Nothing is wasted, though the brevity reflects sparse content rather than tight editing of rich content.
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 no-param, no-annotation, no-output-schema tool, the description is thin: it never explains what a 'capability' description contains or how it relates to the get/preflight siblings. An agent can tell it is safe to call but not what value it returns.
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 there is no parameter semantics burden. Baseline 4 applies, with no evidence of missing parameter guidance since the schema is empty.
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 verb ('Describe') and a resource ('Belanar public household-water decision capability'), but the resource is abstract and domain-specific jargon that an agent cannot easily map to a concrete operation. It does not distinguish this from siblings get_water_decision or preflight_water_decision, which all appear to operate on the same water-decision domain.
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?
No guidance on when to use this versus the sibling tools get_water_decision and preflight_water_decision. The word 'Read-only' implies a safe inspection call, but the agent is left to infer whether this discovers capabilities, returns metadata, or acts as a prerequisite for the other two.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Return Belanar household-water decision support. Never contacts, books, hires, purchases from, or pays a provider.
| Name | Required | Description | Default |
|---|---|---|---|
| symptom | Yes | ||
| duration | No | ||
| location | Yes | ||
| constraints | No | ||
| authority_scope | No | decision_only | |
| warning_signals | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden, and it does disclose one meaningful trait: the tool never contacts, books, hires, purchases from, or pays any provider, signaling a purely advisory/no-side-effect operation. It says nothing about permissions, rate limits, or whether the output is a recommendation vs. a plan, so coverage remains partial.
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 tight sentences with the core purpose front-loaded and no filler. It is efficiently sized, though extremely terse given the tool's parameter complexity.
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?
With no output schema, no annotations, and six parameters at 0% schema coverage, the description is far too thin. It neither explains the return shape (diagnosis? recommendation? urgency?) nor documents the inputs, so the agent lacks enough to call it correctly.
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 6 parameters (symptom, location, duration, constraints, authority_scope, warning_signals), and the description adds no meaning for any of them. Crucially, authority_scope defaults to decision_only with no explanation, and warning_signals/constraints are left wholly undefined, so an agent cannot populate them correctly.
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 names a specific verb+resource ("Return Belanar household-water decision support"), so the agent knows this yields a recommendation rather than performing an action. However, it offers no differentiation from the siblings preflight_water_decision and describe_water_capability, leaving the agent unable to tell which of the three decision-related tools to call.
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 statement of when to use this tool versus its two siblings, nor prerequisites or context. The only guidance is a negative scope exclusion (never contacting/booking/paying a provider), which constrains behavior rather than telling the agent when this tool is the right choice.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Check scope and material inputs. No external action.
| Name | Required | Description | Default |
|---|---|---|---|
| symptom | No | ||
| location | No | ||
| authority_scope | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full behavioral burden. 'No external action' usefully indicates the tool has no side effects, but it says nothing about permissions, validation behavior, failure modes, or what the check returns.
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 description is very short and front-loads a partial purpose, but its brevity reflects under-specification rather than efficient completeness. 'No external action' is a fragment that does not earn its place 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?
For a tool with three undocumented parameters, no annotations, and no output schema, the description is far too thin. An agent cannot determine what inputs to provide or what a successful preflight response means.
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 schema has three parameters with 0% description coverage, and the description does not mention symptom, location, or authority_scope at all. It fails to compensate for the missing parameter semantics.
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 gives a verb ('Check') and a vague object ('scope and material inputs'), but it does not clearly state what a water decision preflight actually validates or how it relates to siblings like get_water_decision. An agent can infer it is a preliminary validation step, but the purpose remains under-specified.
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 only usage-like signal is 'No external action,' which hints at a safe, non-mutating call but does not say when to use this tool instead of describe_water_capability or get_water_decision. There are no prerequisites, exclusions, or alternative-routing instructions.
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.
describe_water_capabilityget_water_decisionpreflight_water_decisionHuman-in-the-loop for AI agents over MCP: durable approvals with a hosted review page & audit trail
Decision-assurance for AI agents: an auditable action boundary + receipt before it acts.
MCP server for the Fail Modes taxonomy — a knowledge base of AI system failure modes
Add one secure layer between your agents and this server.
