GeoRescue MCP Server

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

With no annotations, the description carries the behavioral burden. It usefully discloses the default behavior (comparing the two most recent runs), but it does not state whether the operation is read-only, what the output looks like, or any preconditions such as run validity.

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, front-loaded sentence with no wasted words. The parenthetical default note is placed appropriately.

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 comparison tool with no output schema and no annotations, the description is too thin. It omits the shape of the comparison result, how checks are matched, and how to specify runs beyond an implicit default.

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 are two parameters, so the description must compensate. It only alludes to the parameters as 'two runs' and the default behavior; it does not explain what values run_a and run_b accept or that null triggers the default.

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 states a specific verb and resource: comparing issue counts by check between two runs. It is distinguishable from siblings like find_issues or explain_issue, though it does not explicitly name alternatives.

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?

It implies usage when comparing two runs and explains the default when runs are omitted. However, it gives no guidance on when to prefer this over find_issues or other sibling tools, nor any exclusions.

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

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

No annotations are provided, so the description carries the full burden, yet it says nothing about read-only nature, behavior for unknown tables, or error cases. It only asserts the shape of the returned information.

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?

One short sentence with no filler and the key concept front-loaded. It is fragmentary and slightly under-specified rather than padded.

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 simple single-parameter read tool this covers the essential output (columns and types), but with no annotations and no output schema, the description should also say what a failure looks like and confirm there are no side effects.

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 0% with a single 'table' string parameter, so the description must compensate. The examples ('issues', 'cases') give the agent real domain values to pass, which is genuinely useful, but there is no note on naming conventions, case sensitivity, or what happens for invalid names.

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 resource (columns and types) tied to a results-store table, with concrete table examples ('issues', 'cases'). It is distinguishable from sibling list_tables, though the verb is only implied by the name rather than stated in the description.

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 call this versus inspect_dataset, list_tables, or run_query. An agent must infer that this is the schema-introspection step before querying.

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

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. It usefully discloses that the response includes detection thresholds, the automatic action, and typical causes, which is meaningful beyond the schema, but it does not explicitly confirm that the tool is read-only and side-effect-free, nor does it mention any auth or rate-limit constraints.

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 a single, front-loaded sentence with no redundant filler. Each part earns its place by naming the purpose, the expected input style, and the returned explanatory 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 one-parameter explanatory tool with no annotations or output schema, the description is largely complete: it explains the input concept and what the response will contain. It falls short only on explicit read-only behavior and on whether `check` values are validated against an enumeration.

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 the description must supply parameter semantics. It does explain that the single `check` parameter is an issue type or site term and gives three concrete examples, but it does not say whether values must be exact slugs, whether there is a canonical list, or how to handle unknown terms.

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 states a specific verb and resource: it explains an issue type or site term in plain English. The examples ('sliver_polygon', 'closure', 'iou') clarify what counts as a check and distinguish this explanatory tool from action-oriented siblings like find_issues or repair_dataset.

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 description implies when the tool is useful—when an agent needs to understand an issue term, its thresholds, automatic action, or causes—but it does not explicitly say when to use this instead of siblings such as find_issues or inspect_dataset. There are no exclusions or alternative-routing guidance.

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

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

With no annotations, the description carries the full burden; it does disclose that results are capped at `limit` (max 500) and that a total match count is returned alongside the rows, which is genuinely useful. It says nothing about read-only safety, permissions, or what happens when filters are omitted.

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 sentences, front-loaded with purpose then parameter format then return shape; no filler. The second sentence wraps awkwardly but costs no clarity.

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?

The absence of an output schema is partly offset by describing the return (count plus rows), but with no annotations and 0% schema coverage the description leaves too much open — filter value formats and default behavior when nothing is supplied.

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 0%, so the description must compensate. It fully documents bbox (order plus EPSG:4326) and hints at limit's cap, but check, severity, and parcel_id — three of five parameters — are never mentioned, leaving their accepted values and semantics unknown.

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?

"Filter issues in the latest run" gives a specific verb and resource plus scope (latest run), which separates it from explain_issue and compare_runs. It stops short of naming those siblings explicitly, so an agent still has to infer the boundary.

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 versus explain_issue (drill into one issue) or compare_runs (cross-run diff). The 'latest run' qualifier hints at scope but no alternatives or exclusions are given.

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

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

No annotations are provided, so the description carries the full burden. It usefully discloses the returned payload (verdict, confidence, deed check with closure and IoU, parcel issues), which substitutes for a missing output schema. However, it says nothing about whether the call is read-only, error behavior when a case is not found, or what happens if both/neither identifier is supplied.

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 sentence, front-loaded with the lookup keys and followed by the returned fields, with no filler. The nested parentheticals are slightly dense but each carries useful format or payload information.

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 two-parameter lookup with no annotations and no output schema, the description covers both input formats and the return contents, which is most of what an agent needs. The remaining gap is requiredness/precedence between the two optional identifiers.

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?

With 0% schema coverage, the description must do the work, and it does add real value by supplying concrete identifier formats ('0015420010__0015315300' vs '001542 0010') that the bare null-typed string fields do not convey. It stops short of stating whether exactly one identifier is required or which wins if both are passed.

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 opens with a specific verb and resource ('One case file by case_id ... or by a parcel ID') and enumerates the payload (verdict, confidence, ORB refs, deed check, issues), so the agent knows exactly what it retrieves. It does not reference any sibling tool, so differentiation from the inspect/query tools is left implicit.

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?

It states the two valid lookup keys and gives concrete example formats, which implies when the tool applies. But there is no explicit guidance on when to pick this over siblings like find_issues, explain_issue, or run_query, and no exclusions.

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

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

With no annotations, the description carries full burden: it does disclose the return payload (rows, the SQL used, caveats), which is genuinely useful context for trusting results. It says nothing about whether the call is read-only, what permissions or validation apply, or what happens when a metric name is unknown.

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 core action and followed by the return contract. No filler, though the grouping behavior could be folded in without bloat.

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?

The description covers the return shape in lieu of an output schema, which is good, and it is adequate for the required 'name' parameter. However, the optional grouping parameter and the distinctness from run_query remain unexplained, leaving meaningful gaps for a two-parameter analysis tool with no annotations.

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 both parameters need the description to compensate. It implies 'name' is a metric identifier defined in metrics.yml, which adds real meaning, but 'group_by' is never mentioned — an agent must guess its accepted values and effect on output shape.

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?

Specific verb + resource: 'Compute a governed metric from semantic/metrics.yml', plus a claim about what comes back. This distinguishes it reasonably from generic siblings like run_query or list_metrics, though it never names them explicitly.

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 phrase 'governed metric from semantic/metrics.yml' implies this is the path when an approved metric definition exists rather than ad-hoc SQL, and the sibling list (run_query, list_metrics) makes the contrast inferable. But no explicit when/when-not or prerequisite (e.g., call list_metrics first to find a valid name) is stated.

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

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

With no annotations, the description does real work by disclosing read-only behavior and that include_wkt returns each issue's geometry as working CRS WKT. However, it does not explain the return shape, default filtering behavior, config_path effects, or pagination behavior beyond the parameter names.

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 two short sentences, front-loaded with the core operation and then the main filtering/pagination/output switches. It is efficient, though the second sentence is a dense list and the first sentence's broad 'inspect' framing sits slightly awkwardly with the issue-focused detail that follows.

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 7-parameter read-only tool with no annotations, no output schema, and 0% schema description coverage, the description covers the main filtering, paging, and include_wkt behavior. It remains incomplete because path and config_path are undocumented and the return structure and default behavior when filters are omitted are not described.

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 the description must carry parameter meaning. It clarifies check name(s), severity(ies), limit/offset pagination, and include_wkt geometry output, but says nothing about the required path parameter's expected value or the config_path parameter, and gives no accepted check/severity values.

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 states a specific verb and resource: inspect a parcel dataset read-only, and clarifies that it filters issues. It is understandable without opening the schema, but it does not explicitly distinguish this tool from siblings such as find_issues or explain_issue.

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?

Usage is implied by 'Inspect a parcel dataset (read-only)' and the filtering/paging details, but there is no explicit when-to-use or when-not-to-use guidance. It does not name alternatives like find_issues or repair_dataset, so an agent must infer selection from the operation semantics.

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

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

No annotations are supplied, so the description carries the full burden, but for a zero-parameter tool the risk surface is small. 'Governed' hints that only a curated metric set is returned, which is useful context beyond structured fields, yet nothing is said about ordering, completeness, or whether the set is workspace-scoped.

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?

One short, front-loaded sentence with the verb and resource first and no filler. The parenthetical return-field list slightly duplicates the output schema, which is the only wasted surface.

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?

An output schema exists, so return values needn't be explained, and with no parameters there is little else to cover. The remaining gap is scope — whether the list covers all governed metrics or a filtered subset — which an agent might want before deciding to page or follow up.

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 for the description to disambiguate — baseline 4 applies. The field list in parentheses describes the response shape rather than any input, so it contributes little on this dimension.

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 ('List') and a specific resource ('governed metrics'), and the parenthetical enumerates what each metric carries. That clearly separates it from the singular sibling get_metric, though it never names that sibling explicitly.

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?

Usage is only implied: an agent can infer this is the discovery step before get_metric, but the description never states when to use it, when not to, or which sibling to prefer. No prerequisite or scoping conditions are given.

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

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

With no annotations, the description carries the full burden and does disclose two non-obvious traits: results are scoped to the latest run only and owner names are redacted. It stops short of stating ordering, whether an empty store yields an empty list, or read-only semantics explicitly.

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 front-loaded sentence with the key scoping and redaction caveats in parentheses. Every element earns its place, with no filler.

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?

An output schema exists, so return structure needn't be explained, and with no parameters the surface is small. The description covers the important context (latest-run scope, redaction); only minor details like ordering or empty-result behavior are absent.

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 the baseline is 4; there is no parameter behavior to clarify. The description adds no param detail, but none is needed.

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 (List) and resource (tables) plus the store it targets, so the agent knows exactly what it retrieves. It doesn't explicitly name how it differs from siblings like describe_table or list_metrics, though the 'tables' vs 'table detail' distinction is reasonably evident.

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?

Usage is only implied: an agent can infer this is a discovery step before describe_table or run_query, but the description never says when to use it versus alternatives or what prerequisites exist. No exclusions or alternative routing are stated.

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

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 that the input is never modified, that output is a copy plus a changelog, and that unsafe out_dir values are refused. It leaves out what happens on refusal (error vs. no-op) and nothing about the result payload.

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 dense sentences, front-loaded with the write target and followed by the safety constraints. No filler, and every clause carries a constraint the schema does not express.

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?

Covers the write-safety profile and output location, which is the critical part for a mutation tool with no annotations. But with no output schema and undocumented config_path, the description does not say how a repair is configured or what the caller gets back.

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 0%, so the description must compensate. It gives strong semantics for out_dir (new, non-input, empty) and implies path is the input dataset via 'Never modifies the input', but config_path is never mentioned at all, leaving one of three parameters opaque.

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 resource: writes a repaired COPY of the dataset plus changelog into a NEW folder. That is far more specific than the read-only siblings (inspect_dataset, find_issues, compare_runs), though it never explicitly contrasts itself with them or explains what 'repaired' means.

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 guardrails on when the call is valid: out_dir must be a new folder, must not equal the input's folder, and must not already contain files. It does not name alternatives or say what workflow precedes a repair (e.g. after find_issues/explain_issue).

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

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 declares read-only enforcement, single-statement restriction, row caps (default 100, max 500) and a 10 s timeout, plus the 'check' keyword quoting requirement. It does not say what happens on cap/timeout truncation or whether errors are raised or returned.

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 core action, then limits, then the one syntax gotcha. No filler or restatement of the tool name.

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 2-parameter tool with no output schema, the essentials (single statement, read-only, row cap, timeout, quoting pitfall) are covered. What remains thin is the shape of results and whether truncation is signaled, which an agent would want before relying on the output.

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 0%, so the description must compensate, and it does for both parameters: it constrains 'sql' to one SELECT/WITH statement and warns about quoting the reserved column 'check', and it supplies the effective upper bound of 500 for 'max_rows' which the schema omits. Error/validation behavior for malformed SQL is still unspecified.

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 concrete verb and resource: run one read-only SELECT/WITH query against the 'results store', with the scope constraint of a single statement. An agent can distinguish it from list_tables/describe_table/inspect_dataset, though it never names those siblings explicitly to reinforce the routing.

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?

'Run ONE read-only SELECT/WITH query' implies ad-hoc SQL querying as opposed to metadata inspection, so usage is inferable from the sibling set. There is no explicit when-to-use/when-not guidance, e.g. no statement that schema discovery should go through list_tables or describe_table first.

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