asp-mcp-inspector
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": false
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| check_asp_manifestA | Reads the ASP manifest (/.well-known/agent-shelter.json) of a host and summarises it: protocol version, compliance level (L1-static, L2-transactional, L3-observatory), ingress routes, transport envelope, receipt-signing key, resolution methods and recording rules. Default host: https://agent-shelter.org, the ASP reference node. The manifest is a discovery document: a node with discovery correlation records a terminal signal that follows from the same network within its correlation window, and a node with discovery counters counts the request in aggregate (per document and client class, no address). |
| probe_diagnostic_echoA | Calls the header echo of the ASP reference node (GET https://echo.agent-shelter.org/headers). A first contact gets a local echo of the request's header fields; a repeated call within the ticket lifetime gets the ASP terminal signal instead. Nothing is forwarded. The node records pseudonymised telemetry (salted network hash, User-Agent and header names) when a signal follows a discovery request from the same network; see https://agent-shelter.org/privacy. |
| query_reader_dispositionA | 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. |
| asp_guarded_fetchA | Fetches an http(s) URL with GET (public hosts only, at most 5 redirects, each hop checked, at most 256 KiB). An answer without an ASP signal is returned as data, its text cut at 20 000 characters. An ASP terminal-state signal (HTTP 429, or HTTP 200 with transport_envelope, header Agent-Ticket) states that the resource cannot be obtained through that host; the tool then redeems the single-use ticket at the origin that sent the signal (POST, out of band), reads that host's manifest (/.well-known/agent-shelter.json, a discovery request) and verifies the Ed25519 receipt against the public key published there. From then on, for the lifetime of this server process, every call for the same resource - the requested URL, each redirect hop and the URL the signal names - is answered from that receipt without a request. The redemption is recorded by the node like any receipt (on the reference node pseudonymised, see https://agent-shelter.org/privacy); the receipt documents a terminal state on that host, never that the original task was done. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 4 tools
Each tool maps to a distinct ASP interaction: manifest inspection, echo probing, reader disposition query, and guarded fetch. query_reader_disposition and asp_guarded_fetch both involve terminal signals and tickets, but one queries a disposition endpoint while the other performs actual fetching, so the boundary is clear from the descriptions.
All names use snake_case, but the convention is not consistently verb_noun: check_asp_manifest, probe_diagnostic_echo, and query_reader_disposition follow verb-led patterns, while asp_guarded_fetch is prefix/adjective-led and lacks the same verb-first structure. The names remain readable, just not fully predictable.
Four tools is well within the appropriate range for a narrowly scoped ASP inspector. Each tool covers a distinct ASP endpoint or operation, and none appears redundant.
Core inspection and fetching workflows are covered, but there are notable gaps: query_reader_disposition returns a single-use ticket and states that only the signed receipt is proof, yet there is no standalone tool to redeem a ticket or retrieve and verify a receipt obtained independently. The reader drop box for optional context reports also has no dedicated tool.