MCP Selection Lab

scan_mcp_metadata

Create a free public report of MCP tool-description routing collisions.

Reads discovery metadata (initialize/tools/list) only; never calls target business
tools or spends funds. Use a public HTTP(S) URL without credentials, query or fragment.
Results use at most 12 tools and 24 generated cases, not a real-model evaluation.
Reports persist and are public by link. For an existing report use get_selection_report.
Set internal_test=true for owner/CI validation so it is excluded from public scans.
source is a self-reported referral bucket, not identity verification.

Input Schema

TableJSON Schema

Name	Required	Default
`source`	No	other
`mcp_url`	Yes
`internal_test`	No

Output Schema

TableJSON Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections. Dates show when Glama detected each change.

First observedSep 6, 2026

TDQS

A5/5.0

Behavior5/5

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

With no annotations provided, the description carries the full burden and does so exceptionally: it discloses that the tool only reads discovery metadata, never calls business tools or spends funds, is limited to 12 tools/24 cases, persists reports publicly, and treats source as non-verifying.

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

Conciseness5/5

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

Every sentence contributes unique operational information: purpose, safety, URL constraints, limits, persistence, sibling routing, and testing flag. The description is front-loaded with the core purpose and then adds necessary caveats without repetition or filler.

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?

The output schema exists, so return-value documentation is not the description's burden. Given the tool's complexity, the description covers safety behavior, input constraints, limitations, persistence semantics, and sibling alternatives. An agent has enough context to invoke it correctly.

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

Parameters5/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 explain parameters itself. It does: mcp_url is a public HTTP(S) URL without credentials/query/fragment, internal_test excludes the scan from public results, and source is a self-reported referral bucket. All three parameters are meaningfully clarified.

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: 'Create a free public report of MCP tool-description routing collisions.' It clearly distinguishes this from sibling get_selection_report by stating that existing reports should be retrieved there instead. The scope is unambiguous.

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 gives explicit input constraints: public HTTP(S) URL without credentials, query, or fragment. It also tells the agent when to use the sibling tool get_selection_report and when to set internal_test=true, providing concrete routing guidance.

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

All MCP Selection Lab tools Inspect

Try in Browser

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A4.6/5.0

Disambiguation5/5

Each tool serves a clearly distinct function: creating a scan, retrieving a report, and getting service information. The descriptions explicitly cross-reference the report retrieval path, leaving no boundary ambiguity.

Naming Consistency4/5

Most names follow a clear verb_noun pattern (get_selection_report, scan_mcp_metadata), but selection_lab_info is a noun phrase rather than an action-oriented name. All names are snake_case and readable, so the deviation is minor.

Tool Count5/5

Three tools is an appropriate scope for this service: scan creation, report retrieval, and service info. Each tool serves a distinct user need without redundancy or bloat.

Completeness5/5

The tool surface covers the full user journey: learn about the service, create a scan, and later retrieve the resulting report. No update/delete/list operations are needed because reports are public and effectively immutable, and service details are covered by selection_lab_info.

Resources

Need Help?