Skip to main content
Glama
nullkommaneun

asp-mcp-inspector

by nullkommaneun
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Remote

Query the ASP reader's disposition

query_reader_disposition

Checks how the ASP reference reader treats a target URL, returning a terminal signal and single-use ticket that can be redeemed for a signed proof receipt.

Instructions

Asks the reader of the ASP reference node what it does with a target URL (GET https://reader.agent-shelter.org/v1/reader?url=<target_url>&envelope=200). The reader never fetches the target: it answers with the ASP terminal signal (RFC 9457 problem details, terminal true, success_probability 0) and a single-use ticket (48 characters, also in the header Agent-Ticket and in an absolute resolution_uri), carried with HTTP 200 because of envelope=200; the ticket maps to a signed receipt by POST or, where resolution_methods lists GET, by GET, and only that receipt is a proof. Its drop box takes one optional context report, by POST or, where listed, by GET with query parameters. The target URL is sent to agent-shelter.org, which records it (shortened, secrets scrubbed) with pseudonymised client data when the request follows a discovery request from the same network or the ticket is redeemed; see https://agent-shelter.org/privacy.

Input Schema

NameRequiredDescriptionDefault
target_urlYesThe http(s) URL the agent wanted to read

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A4/5.0
Behavior5/5

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

With annotations only covering safety flags, the description adds rich behavioral context: the reader never fetches the target, returns a terminal RFC 9457 signal with success_probability 0, issues a single-use 48-character ticket available in the header and resolution_uri, and explains that only the signed receipt is proof. It also discloses privacy/data-recording behavior and links to the privacy policy, which is exactly the kind of context annotations can't carry.

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 purpose is front-loaded, but the remainder is a dense, run-on paragraph packing ticket mechanics, resolution methods, drop-box behavior, and privacy into one block. Most content earns its place, but it's not structured for quick scanning and could be broken into clearer clauses.

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?

There's no output schema, so the description carries the burden of explaining the return: the terminal signal, the ticket format, its locations, and the resolution path. It also covers the optional context-report drop box and data handling, leaving no significant gap for an agent to call it correctly.

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

Parameters4/5

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

Schema coverage is 100%, so the single parameter is already documented as an http(s) URL up to 2048 chars. The description adds meaningful semantics beyond the schema by noting the URL is transmitted to agent-shelter.org and stored shortened with secrets scrubbed, which affects how an agent should construct the input.

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 states a specific verb and resource: it asks the ASP reference node's reader what it does with a target URL, and clarifies upfront that the reader never fetches the target. That distinguishes it implicitly from asp_guarded_fetch, but no sibling is named, so the differentiation isn't explicit.

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

Usage Guidelines3/5

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

Usage context is implied (the reader returns a terminal signal and a ticket, so this is a pre-fetch disposition check), and the drop-box behavior is mentioned. However, there's no explicit statement of when to choose this over asp_guarded_fetch or probe_diagnostic_echo, and no exclusions.

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