Evidenceline

Ask the guidelines

search_guidelines

Read-onlyIdempotent

Search public environmental guidance and retrieve cited passages with page-level citations, headings, and official links. Get clear 'not covered' results when no passage matches.

Instructions

Search the indexed public guidance (ASC NEPM Schedule B1, PFAS NEMP 3.0, DWER guidelines on assessing and on reporting and classifying contaminated sites, and the ADWG PFAS fact sheet) and return the passages that match.

Each passage gives the document title, edition and date, its WA status, the PDF page and the printed page number, the nearest section heading and the headings above it, a short excerpt (shorter for documents whose licence allows only brief quotes, always with the notice) and the official link. At most one passage comes from any one page. When no passage covers enough of the question, the result is 'not covered' with the reason, instead of weak matches.

Never take a guideline value from an excerpt: tables extract badly. For PFAS drinking-water values use lookup_limit; for any other value, read it on the cited page. The tool never says which document or edition applies to a site. PFAS NEMP 3.1 is not indexed (its host was unreachable when the index was built).

Input Schema

TableJSON Schema

Name	Required	Description	Default
`k`	No	How many passages to return, 1 to 10. Default 5.
`question`	Yes	A question in plain English, for example 'What must a detailed site investigation report include?' or 'Can PFAS-contaminated soil be reused?'. At most 500 characters.

Output Schema

TableJSON Schema

Name	Required	Description
`notes`	Yes
`status`	Yes
`passages`	Yes
`question`	Yes
`explanation`	Yes	What the result means, in plain English.
`searched_terms`	Yes	The terms searched for, after synonym expansion.
`indexed_documents`	Yes
`unavailable_documents`	Yes	Documents listed in the corpus but not indexed, and why.

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.1.0Sep 24, 2026

TDQS

A4.6/5.0

Behavior5/5

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

Annotations already mark the tool read-only and idempotent, but the description adds substantial behavioral detail beyond that: at most one passage per page, the 'not covered' outcome with reasons instead of weak matches, the fact that PFAS NEMP 3.1 is not indexed, and the warning about table extraction. This is rich, non-obvious behavior that structured fields alone would not convey.

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 longer than average but every sentence carries a distinct piece of information: scope, return fields, deduplication, not-covered behavior, value-extraction caveat, and indexing limitation. It is front-loaded with purpose and return behavior before caveats. Slight redundancy with the schema's plain-English example prevents a perfect score.

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 search tool with two simple parameters, an output schema, and read-only annotations, the description covers everything an agent needs: what corpus is searched, what each passage contains, how non-answers are reported, which sibling to use for values, and what the tool cannot tell the user. Nothing critical is missing.

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?

Schema description coverage is 100%, so the schema already documents 'question' and 'k' with examples and constraints. The description reinforces the plain-English question format but adds little new parameter-level meaning beyond what the schema provides. It compensates with usage-level guidance, not parameter semantics, so the baseline 3 is appropriate.

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 opens with a specific verb and resource: 'Search the indexed public guidance... and return the passages that match.' It names the exact document set (ASC NEPM, PFAS NEMP 3.0, DWER guidelines, ADWG fact sheet), so an agent can identify the tool's scope. It also differentiates from lookup_limit, which is explicitly routed to for PFAS drinking-water values.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explicitly tells the agent when not to trust the tool's excerpts for numeric values: 'Never take a guideline value from an excerpt: tables extract badly.' It names the alternative tool and condition: 'For PFAS drinking-water values use lookup_limit.' It also states a hard limitation, 'The tool never says which document or edition applies to a site,' giving clear when-not-to-use context.

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

Deploy Server