Dechonet MCP

MCP Server Check

mcp_server_check

Read-onlyIdempotent

Check a remote MCP server from outside before connecting it to an agent: verify authentication, risky tool actions, poisoning text, CORS, HTTPS, and annotations without calling any tool.

Instructions

Check a remote MCP server from outside before connecting it to an agent: whether it requires authentication (and publishes OAuth protected-resource metadata, RFC 9728), which of its tools act on the world (run commands, write or delete files, send messages, make payments, read secrets), whether its server instructions or tool and parameter descriptions contain text that steers an agent (tool poisoning), whether a web page on any site could call it (CORS and Origin), HTTPS, and tool annotations. Sends initialize and tools/list only — no tool is ever called; query strings are removed before anything is sent or stored. Public addresses only. Findings cover what the server shows from outside: what a tool does when called, the server code and tools behind a login are not checked and are listed as not checked. Read-only; requires no API key; rate-limited. Returns status, KPIs, issues, actions, what was not checked, and a shareable report link.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`url`	Yes	The remote MCP endpoint (e.g., 'https://example.com/mcp'). Query strings are removed.

Output Schema

TableJSON Schema

Name	Required	Description
`kpis`	No	Key metrics as label/value pairs
`grade`	No	Letter grade (A+ to F) when the tool grades the target
`score`	No	0-100 score when the tool scores the target
`issues`	No	Detected problems, severity-rated
`status`	Yes	Overall verdict, e.g. 'good' \| 'warning' \| 'bad' \| 'info' \| 'unknown'
`actions`	No	Recommended next actions, most important first
`summary`	No	One-paragraph interpretation of the result
`receipts`	No	Signed observation receipts behind this result, one per lookup: when, from where and under which rules version DechoNet observed it. Each url shows the record and checks its Ed25519 signature.
`reportUrl`	Yes	Human-facing interactive report for this exact lookup on dechonet.com
`observation`	No	How much was actually observed and when. A partial observation means some checks did not answer: missing parts are not verified, never clean.

Schema Changelog

Changes observed during successful MCP inspections.

Addedv1.6.1Oct 18, 2026

TDQS

A4.6/5.0

Behavior5/5

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

Annotations already declare read-only/idempotent/open-world, but the description adds substantial behavior beyond them: it only sends initialize and tools/list, never calls a tool, strips query strings before sending or storing, restricts to public addresses, requires no API key, and is rate-limited. It also discloses what is deliberately not checked and what the response contains.

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

Conciseness4/5

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

Front-loaded with the core action, and given the breadth of what is checked the length is largely justified. It is one dense run-on paragraph with heavy parentheticals (RFC 9728, tool poisoning, CORS and Origin) that would read better as a short list, costing it a point.

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?

An output schema exists, so return values need not be detailed, yet the description still summarizes the return (status, KPIs, issues, actions, unchecked items, shareable report link). Combined with scope limits, transport behavior, and access constraints, an agent has everything needed 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?

With a single parameter at 100% schema coverage the baseline is 3, but the description adds a real constraint not in the schema: only public addresses are accepted, and it reinforces the query-string stripping with the rationale that nothing is sent or stored with the query.

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?

States a specific verb and resource ('Check a remote MCP server from outside') and enumerates exactly what is inspected: auth/OAuth metadata, world-acting tools, tool-poisoning text, CORS/Origin, HTTPS, annotations. This is clearly distinguishable from siblings like ssl_check or security_scan, which cover narrower surface areas.

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

Usage Guidelines4/5

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

The intended moment is explicit: 'before connecting it to an agent.' It also implicitly defines when-not by stating what is out of scope (behind-login code, actual tool behavior) and flagging those as 'not checked.' It does not, however, name a sibling tool as an alternative for related checks.

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