Deterministic pool and spa water test log. Checks readings against US CDC ranges. No AI.
Scored across 6 tools
Each tool maps to a distinct operation: create_site, add_readings, check_readings, get_log_summary, get_rules, request_operator_signoff. The only surface overlap is that check_readings and get_log_summary both report CDC-range issues, but one validates an arbitrary list while the other summarizes an existing log, and descriptions make this clear.
All six tools use consistent snake_case with a verb_noun pattern (add_readings, check_readings, create_site, get_log_summary, get_rules, request_operator_signoff). No mixing of conventions.
Six tools is a well-scoped set for a water-test log service: create, append, validate, summarize, retrieve rules, and request signoff. No tool feels redundant or missing at this count.
Core lifecycle is covered: create a site, add readings, check them, retrieve a full summary (including every reading), get the rule table, and request operator signoff. Minor gaps exist: no update/delete for readings or sites, and no list_sites to recover a site id, but these are workable for an append-only log.
Append water readings to an existing log. Requires a bearer key.
| Name | Required | Description | Default |
|---|---|---|---|
| site_id | Yes | ||
| readings | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations, so description carries the full burden. It discloses an auth requirement ('Requires a bearer key'), which is valuable behavioral context. However, it doesn't mention append-vs-overwrite semantics, validation of readings, rate limits, or return behavior.
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 purpose then auth requirement. No padding, though it is arguably too terse given the coverage gaps.
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?
A two-parameter write tool with no annotations, no output schema, and 0% schema description coverage. The description provides almost none of the missing behavioral or parameter context needed 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%, so parameters are undocumented in the schema. The description doesn't explain site_id or the structure of readings array items, leaving both parameters semantically opaque for the agent.
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 specific verb+resource (append water readings) and target (existing log), which clearly distinguishes it from sibling check_readings. Lacks detail on which log or units, but the core purpose is unambiguous.
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 explicit when-to-use vs alternatives (check_readings, get_log_summary). The 'existing log' constraint implies a prerequisite but doesn't state whether the log must already exist or how to create one.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Check a list of pool or spa water readings for things that cannot be true, and compare pH, free chlorine and bromine against the ranges published on the US CDC pages. Deterministic arithmetic only - no AI. It does not decide whether a pool is legally compliant, and it does not know your local code.
| Name | Required | Description | Default |
|---|---|---|---|
| as_of | No | Treat this date as "today" (YYYY-MM-DD) when rejecting future timestamps. Defaults to the server date. | |
| readings | Yes | Readings to check. Each: {at:"YYYY-MM-DDTHH:MM", kind:"pool|hot_tub|splash_pad|wading_pool|other", ph?:number, free_chlorine_ppm?:number, total_chlorine_ppm?:number, bromine_ppm?:number, cyanuric_acid_ppm?:number, water_temp_f?:number, disinfectant?:"chlorine|bromine|none", method?:"dpd|test_strip|meter|other", by?:"who tested"}. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and does well: it discloses deterministic arithmetic, no AI involvement, and the explicit boundaries of what the tool will not judge. It still omits operational details such as whether problems are returned as a list, severity levels, or auth requirements.
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?
Three short sentences, each earning its place: capability, method, and limitations. The core purpose is front-loaded and nothing is redundant.
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 checker with no output schema and no annotations, the description covers intent, method, and limits well. It would be stronger if it sketched the shape of the result (e.g., list of flagged readings/failed range checks), which is the one thing an agent cannot infer from structured fields.
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 100% – both parameters, including the nested reading shape and the as_of default, are fully documented in the schema. The description adds no parameter syntax or format detail beyond that, so the baseline 3 applies.
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 specific verb (check) and resource (pool/spa water readings) plus two distinct scopes: internal plausibility ('things that cannot be true') and comparison against US CDC pH/free chlorine/bromine ranges. This differentiates it cleanly from siblings like add_readings and get_rules.
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?
Gives clear when-not guidance ('does not decide whether a pool is legally compliant', 'does not know your local code'), which steers the agent away from over-trusting the result. It does not explicitly route to a sibling (e.g., get_rules for jurisdiction-specific ranges), so it falls short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Open a water-test log for one pool, hot tub or splash pad (returns a site id). Requires a bearer key.
| Name | Required | Description | Default |
|---|---|---|---|
| label | No | What to call this water, e.g. "Apartment pool - north". | |
| address | No | ||
| water_type | No | pool | hot_tub | splash_pad | wading_pool | other | |
| disinfectant | No | chlorine | bromine | none | |
| volume_gallons | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry the behavioral load; it usefully discloses the auth requirement ('Requires a bearer key') and that a site id is returned. It does not cover whether creation is idempotent, what happens on a duplicate label/address, or any rate limits.
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?
A single tight sentence that front-loads the action, scopes the resource, and appends the return value and auth requirement with zero filler. Every clause earns its place.
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?
No output schema and no annotations mean the description should do more for a 5-parameter mutation tool: all parameters are optional yet the description never says whether a bare create is valid, nor what happens on conflicting duplicates. It does at least flag the returned site id and the bearer key, which an agent needs to chain into add_readings.
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 coverage is 60% (label, water_type, disinfectant documented; address and volume_gallons undocumented), and the description adds no parameter meaning at all. Nothing compensates for the two bare parameters, and the description's mention of 'pool, hot tub or splash pad' merely echoes the water_type enum values already in the schema.
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 specific verb ('Open') and a specific resource ('a water-test log for one pool, hot tub or splash pad'), plus the return value ('returns a site id'). It is clearly the creation step among read/write siblings (add_readings, check_readings, get_log_summary), though it never names a sibling to sharpen the contrast.
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 'open a log first, returns a site id' framing implies this is the entry point before add_readings/check_readings, but that sequencing is left to inference. There is no explicit when-to-use, when-not-to-use, or named alternative.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Every reading, the flagged issues, the CDC-range counts, the longest gap between tests, and the A4 log sheet URL, for one log. Requires a bearer key.
| Name | Required | Description | Default |
|---|---|---|---|
| site_id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full behavioral burden. It usefully discloses the auth requirement (bearer key) and enumerates the returned contents, but omits whether the operation is read-only, pagination/limits, or error behavior.
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?
A single tightly-packed sentence with the content list front-loaded and the auth note last. Dense but free of filler and correctly sized for a one-parameter getter.
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, the description usefully enumerates the return contents and flags the auth need, which covers the biggest gaps. It still leaves the site_id semantics unclarified, so it is adequate but not fully complete.
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% and there is one required site_id parameter. The phrase 'for one log' hints that the parameter selects a single log, but given the parameter is named site_id, the mapping is ambiguous and no format or scope detail is provided.
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 enumerates what the tool surfaces (readings, flagged issues, CDC-range counts, longest gap, A4 log sheet URL) for one log, which lets an agent infer a log-summary getter. However, it uses no verb and reads like a return-value list rather than stating the action, and it does not distinguish itself from siblings like check_readings.
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 when-to-use guidance, no statement of prerequisites beyond auth, and no mention of alternatives such as check_readings. The agent is left to infer the tool's role from the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
The exact rule table this service checks against, the quoted source of every range, and what it explicitly does not claim. Quote it if you need to explain a result.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
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 a useful scope trait — that the table includes 'what it explicitly does not claim.' It does not state read-only nature, freshness/versioning of the rule table, or the response format, leaving meaningful behavioral gaps.
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, zero filler: the first front-loads what the return contains, the second gives the usage cue. Every clause earns its place.
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 and no annotations, the description should describe the return, and it does so in three concrete clauses (rule table, quoted sources, non-claims). Only minor gaps remain — output format and whether the table is versioned/cached — for a zero-parameter read tool.
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 nothing to document and the baseline of 4 applies. No parameter description could add value here.
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 the specific resource with distinctive detail — 'the exact rule table this service checks against' plus quoted sources and explicit non-claims — so an agent can tell it apart from the readings/site/log siblings. However, it is a noun phrase with no verb and never explicitly contrasts itself with any sibling tool, so it stops short of a 5.
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?
'Quote it if you need to explain a result' gives a concrete triggering condition tied to the sibling workflow (check_readings produces results, get_rules explains them). It offers clear context but no explicit when-not-to-use or named alternative.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a one-time URL the pool operator can open to confirm the log. Requires a bearer key. The token is single use.
| Name | Required | Description | Default |
|---|---|---|---|
| site_id | Yes | ||
| provider_name | No | ||
| provider_email | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral burden, and it does disclose two useful traits: a bearer key is required, and the token is single use. It omits expiry behavior, what happens on reuse, and whether invoking it sends anything to the provider — meaningful gaps for a token-issuing tool.
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?
Three short sentences, front-loaded with the action and deliverable, with no filler. Efficient, though the second and third sentences are terse enough that they could carry more detail at minimal cost.
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 three-parameter mutation tool with no annotations and no output schema, the description covers the core action and auth but leaves parameter meaning and failure/expiry semantics unaddressed. Adequate to start, not complete enough to invoke confidently.
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% for three parameters, so the description must compensate and largely does not. It never explains site_id, and provider_name/provider_email are only obliquely gestured at via 'the pool operator' — an agent cannot tell whether those are required, who receives the URL, or what the URL is bound to.
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 specific verb and deliverable: creates a one-time URL for the pool operator to confirm the log. The purpose is immediately legible. It does not differentiate from siblings, though the sibling set (add_readings, check_readings, create_site, get_log_summary, get_rules) is distant enough that confusion is unlikely.
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 explicit when-to-use or when-not-to-use guidance. 'confirm the log' implies a sign-off workflow but never says at which point in the workflow to call this, nor whether an alternative exists for non-operator confirmation.
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.
add_readingscheck_readingscreate_siteget_log_summaryget_rulesrequest_operator_signoffDeterministic check of logged service hours: bad dates, impossible totals, duplicates. No AI.
Septic maintenance record: log inspections and pump-outs; next due date under EPA intervals. No AI.
Log golf rounds in ChatGPT/Claude; scorecards, trends, unofficial WHS math.
Doctor-reviewed blood-test markers, conditions & symptoms as agent tools. EN/RU/HE. Hosted.
Add one secure layer between your agents and this server.
