Skip to main content
Glama
Sign In

Passage Data — cited environmental limits

by io.github.kedu21-beep
OverviewDiscussionsAdmin

List the instruments held

list_sources
Read-onlyIdempotent

Which regulations, and which editions, does an answer for a place rest on? Every regulation, guideline or permit table we hold for a place: title, issuer, edition, what it governs, how many rows were read from it, and the source URL and sha256. Use it to say what an answer was searched against.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "list_sources"
  }
}

Input Schema

NameRequiredDescriptionDefault
placeNoISO 3166 code of where the rule binds: a country (US, CA, DE, FR, IT), a state or province (US-OH, CA-QC), or EU. A place also searches every place above it: US-OH searches US-OH and US; DE searches DE and EU. Omit to search everywhere.
mediumNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • changedInput schema / properties / medium / enum
      Previous value: -[
-  "water_discharge",
-  "surface_water",
-  "groundwater",
-  "ambient_air",
-  "air_emission",
-  "sediment",
-  "leachate"
-]New value: +[
+  "water_discharge",
+  "surface_water",
+  "groundwater",
+  "drinking_water",
+  "soil",
+  "ambient_air",
+  "air_emission",
+  "sediment",
+  "leachate"
+]
  2. First observed

TDQS

A3.7/5.0
Behavior4/5

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

Annotations already cover the safety profile (readOnlyHint, idempotentHint, destructiveHint=false, openWorldHint=false), so the description only needs to add context — and it does, by disclosing the return content in detail (title, issuer, edition, governed medium, row counts, source URL, sha256) with no output schema to carry that load. It says nothing about result limits, ordering or exhaustiveness, which keeps it out of 5 territory.

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?

Two sentences, front-loaded with the framing question and then a compact colon-list of contents. The rhetorical opening question is slightly wasteful but does useful framing work; nothing else is padded.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a zero-required-parameter, two-param read-only listing tool with no output schema, the description supplies both purpose and the shape of the returned records, which is what an agent needs. The main gap is the undocumented 'medium' filter, which neither schema nor description explains.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is only 50%: the 'place' parameter is richly documented in-schema, but 'medium' has a bare enum with no description. The description adds no parameter meaning beyond repeating 'for a place' and vaguely gesturing at medium with 'what it governs', so it does not compensate for the coverage gap.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description names the resource concretely — 'Every regulation, guideline or permit table we hold for a place' — and enumerates the fields returned, so an agent knows this is a regulatory-source inventory rather than a site list or a single permit lookup. The list verb is implicit rather than stated, and no sibling is named explicitly, but the resource is clearly distinct from get_permit, list_sites and find_limits.

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?

It gives an explicit use case: 'Use it to say what an answer was searched against,' which frames the tool as provenance/audit support for another answer. There are no exclusions or named alternatives, so it falls short of the 5 bar, but the when-to-use is unambiguous.

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

All Passage Data — cited environmental limits toolsInspect
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.

Resources