Skip to main content
Glama
chris-page-gov

mcp-geo

os_apps_render_feature_inspector

Read-onlyIdempotent

Open the feature inspector to view detailed attributes and linked data for UK geospatial features, enabling direct inspection of ONS and Ordnance Survey datasets.

Instructions

Open the MCP-Apps feature inspector widget.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
toolNo
featureIdNo
linkedIdsNo
contentModeNo
collectionIdNo

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
_metaNo
configNo
statusYes
contentNo
resourceUriNo
instructionsNo
uiResourceUrisYes
structuredContentNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.8.2

TDQS

C2.4/5.0
Behavior2/5

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

Annotations already declare readOnlyHint and idempotentHint, so the description does not contradict them. However, it adds no behavioral context beyond 'Open' – no indication of what the widget displays, how it interacts with the user, or what side effects (if any) it has. With annotations present, the description still fails to provide meaningful transparency.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single sentence, which is efficient and front-loaded with the action. However, it is under-specified rather than concise – it does not include any of the detail an agent needs, so it fails to earn its place.

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

Completeness2/5

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

With 5 parameters, an output schema, and no schema descriptions, the tool is complex enough to require more context. The description offers no information about parameters, return values, or usage scenarios, making it incomplete for an agent to use effectively.

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

Parameters1/5

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

Schema description coverage is 0% and the description mentions none of the 5 parameters (tool, featureId, linkedIds, contentMode, collectionId). An agent receives no help understanding what these parameters do or why they are optional, making the tool nearly impossible to invoke correctly.

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 clearly states a specific action ('Open') and resource ('the MCP-Apps feature inspector widget'), which is distinguishable from sibling render tools by name. However, it does not explain what a 'feature inspector' does or how it differs from other os_apps_render_* widgets, leaving some ambiguity.

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

Usage Guidelines2/5

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

No guidance is given on when to use this tool versus alternatives like os_apps_render_boundary_explorer or os_apps_render_ui_probe. The description provides no context for selection.

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

Deploy Server

Other Tools