Contaminated Land MCP

Overview Schema Source Related Servers Discussions Admin

Draft Section

draft_section

Read-only

Drafts a site report's results and discussion section from screening output and guidance passages, validating every number and citation for a qualified person to check.

Instructions

Draft the results and discussion section of a site report from the screening output and the guidance passages. Every number comes from the screening result and every other claim carries a [chunk_id] citation that the server checks against the passages it supplied; sentences that fail the check are removed and listed in warnings. Client names and addresses are replaced with placeholders before the text goes to the drafting model and restored in the returned draft. This is a draft for a qualified person to check, not a finished or compliance-ready report. Show the returned markdown to the user unchanged, with its citations and warnings; put any comments after it, and add no numbers of your own. Needs OPENROUTER_API_KEY to be set. criteria_set must be one of the ids returned by the list_criteria_sets tool.

Input Schema

TableJSON Schema

Name	Required	Default
`section`	No	results_discussion
`site_id`	Yes
`criteria_set`	Yes

Output Schema

TableJSON Schema

Name	Required	Description	Default
`model`	Yes
`markdown`	Yes
`warnings`	Yes
`citations`	Yes
`redactions`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.1.0Oct 4, 2026

TDQS

A4.4/5.0

Behavior5/5

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

With only readOnlyHint available, the description carries the burden well: it discloses the server-side citation verification, that failing sentences are stripped and surfaced in warnings, that client names/addresses are placeholder-swapped before drafting and restored after, and that the output is an unchecked draft, not compliance-ready.

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?

Purpose and input sources are front-loaded, and the operational instructions (citation handling, warnings, presentation rules) are each doing real work. It is dense but long, with several clauses packed into a single paragraph that could be broken up for scanning.

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?

An output schema exists, so return values need no explanation, and the description still covers the things the schema cannot: citation-checking behavior, warnings, PII handling, the draft disclaimer, and the required API key. Nothing needed to invoke it correctly 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 0%, so the description must compensate and it only partly does: it constrains criteria_set to ids from list_criteria_sets, and 'section' is self-documenting via its const/default. site_id is left completely unexplained in both schema and description.

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 and resource ('Draft the results and discussion section of a site report') plus the two inputs it draws from (screening output, guidance passages). This is clearly distinguishable from siblings list_criteria_sets, search_guidance, and screen_lab_results.

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 a concrete prerequisite chain: criteria_set must be an id from list_criteria_sets, and OPENROUTER_API_KEY must be set. It also prescribes how to present the result, but never states when not to use this tool or explicitly names the sibling that produces the 'screening output'.

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

Deploy Server