Scanned Apr 26, 2026 · 14:32 UTC · streamable-http
4 of 15 checks need a closer look. 11 passed.
Public passive · 8 tools · 11 of 15 rules passed · auth required· 4R · 2W · 1D
The signals that drove the score, in plain language.
No destructive tools in the public surface
No advertised tool matches destructive data verbs (delete, drop, purge, wipe, destroy, truncate). Destructive actions are typically irreversible and should be exposed under explicit, scoped authorization rather than a default `tools/list`.
What to do before you connect this server.
Tools flagged destructive: delete_document. Confirm each is intentional and bounded.
Failing rules at HIGH or CRITICAL severity: no_public_destructive_tools.
Of 8 tools: 2 without input schema. Missing metadata weakens passive risk inference and confuses agents.
Six trust dimensions, each tagged Observed, Inferred, or Derived.
All transport checks passed.
5/5 passed
Two tools omit input schemas.
4/5 passed · 1 failed
OAuth metadata reachable; safe grant types only.
2/2 passed
Destructive, network, and PII signals on the public surface.
0/3 passed · 3 failed
All eight tools have descriptions.
1/1 passed
Per-tool capability and risk inferred from each tool’s name, description, and schema. No tool was invoked.
| Tool | Class | Schema | Capabilities & evidence |
|---|---|---|---|
delete_document Permanently delete a document. | destructive | yes |
|
create_document Create a new document in the user's library. | write | yes |
|
update_document Update an existing document. Accepts free-form string body. | write | missing |
|
run_workflow Run a named server-side workflow. | unknown | missing | — |
fetch_url Fetch the contents of an arbitrary URL. | read | yes |
|
list_users List workspace users, including email addresses. | read | yes |
|
get_document Fetch a single document by id. | read | yes | no high-risk indicators |
search_documents Full-text search across the user's document library. | read | yes | no high-risk indicators |
Per-rule evidence, then the full rule list. Failing rules first.
{
"destructiveTools": [
{
"toolName": "delete_document",
"match": "delete",
"source": "name"
}
]
}Move destructive tools off the public `tools/list` and behind an explicit, scoped authorization step — or split the server into a read-only public endpoint and an authenticated admin endpoint.
{
"withSchema": 6,
"total": 8,
"missing": [
"update_document",
"run_workflow"
]
}Define a JSON Schema for each tool's arguments — at minimum `type: "object"` with named properties and `required` — so callers can validate inputs without invoking the tool.
{
"networkAccessTools": [
{
"toolName": "fetch_url",
"match": "url",
"source": "name"
}
]
}Inferred from a passive probe — AgentReserve never invoked the tool or sent credentials, so behaviour at call time is not observed.
Replace generic fetch tools with purpose-scoped ones that hit specific upstreams under an allow-list. If an unrestricted fetch is intentional, expose it only behind authentication.
{
"piiTools": [
{
"toolName": "list_users",
"match": "email",
"source": "description"
}
]
}Where PII handling is required, document the data minimization, retention, and access controls in the tool description; otherwise remove the PII references from the public schema.
Server identity, protocol version, and TLS transport — the MCP-level signals a client needs before it talks to the server.
MCP Authorization spec — 'Authorization servers and resource servers MUST be served over HTTPS'; matches OWASP ASVS V9 transport requirements.
RFC 6797 — HTTP Strict Transport Security; OWASP ASVS V9.1.
MCP Authorization spec — 'Authorization endpoints and resource endpoints MUST be served over HTTPS.'
MCP base specification — `initialize` result schema requires `protocolVersion`; authorization profile assumes negotiated version.
MCP base specification — `initialize` result schema includes `serverInfo { name, version }`.
Whether the server cooperates with the MCP authorization profile when authorization is in use.
MCP Authorization spec — bearer token usage; defers to RFC 6750 §2 ('Authentication Schemes'), §2.3 forbids URI query parameter tokens for new applications.
MCP Authorization spec — discovery section; references RFC 9728 (OAuth 2.0 Protected Resource Metadata) at `/.well-known/oauth-protected-resource`.
RFC 9728 — does the server publish a `/.well-known/oauth-protected-resource` document, and does it name the right authorization servers?
No scoring rule currently evaluates this standard. The requirement is documented for reference.
RFC 9728 §3 — Protected Resource Metadata Request; documents at `/.well-known/oauth-protected-resource[/<path>]`.
RFC 9728 §2 — `resource` parameter; resource URI must identify the protected resource itself.
RFC 9728 §2 — `authorization_servers` array.
RFC 9728 §3.2 — `signed_metadata` JWT.
RFC 8414 / OpenID Connect Discovery — does the authorization server publish `/.well-known/oauth-authorization-server` with the required endpoints?
No scoring rule currently evaluates this standard. The requirement is documented for reference.
RFC 8414 §3 — Authorization Server Metadata Request, served at `/.well-known/oauth-authorization-server`.
RFC 8414 §2 — `issuer` field; §3.3 — validation rules.
RFC 8414 §2 — `authorization_endpoint`.
RFC 8414 §2 — `token_endpoint`.
RFC 8414 §2 — `jwks_uri`.
RFC 8414 §2 — `registration_endpoint`; RFC 7591 — Dynamic Client Registration.
RFC 9700 — current OAuth security guidance: PKCE, no implicit grant, audience-restricted tokens, careful redirect URIs.
RFC 9700 §2.1.1 — Redirect URI validation; §4.1 — Open redirector mitigation.
RFC 9700 §2.1 — 'Clients MUST use authorization code grant with PKCE'; RFC 7636 — PKCE.
RFC 9700 §2.1.2 — implicit grant prohibited; §2.4 — resource owner password credentials grant prohibited.
RFC 9700 §4.10 — Audience restriction; RFC 8707 — Resource Indicators for OAuth.
Heuristic alignment with the OWASP MCP Top 10 — keyword-driven indicators inferred from the public tool surface.
OWASP MCP Top 10 — Token / secret exposure (sensitive data disclosure through MCP tool surface).
OWASP MCP Top 10 — Scope creep / excessive privilege (over-broad capability surface).
OWASP MCP Top 10 — Tool poisoning (malicious or ambiguous tool definitions tricking agents into harmful calls).
OWASP MCP Top 10 — Insufficient authentication / authorization (sensitive capability exposed without identity or scope checks).
OWASP MCP Top 10 — Lack of telemetry / audit (no observable record of tool invocation).
OWASP MCP Top 10 — Context over-sharing (tools that pull excessive or PII-laden context into the agent).
Every tool returned by `tools/list` includes a non-empty JSON Schema for its arguments. Schema-less tools force agents to guess argument shapes and make pre-call validation impossible.
{
"withSchema": 6,
"total": 8,
"missing": [
"update_document",
"run_workflow"
]
}No advertised tool matches destructive data verbs (delete, drop, purge, wipe, destroy, truncate). Destructive actions are typically irreversible and should be exposed under explicit, scoped authorization rather than a default `tools/list`.
{
"destructiveTools": [
{
"toolName": "delete_document",
"match": "delete",
"source": "name"
}
]
}No advertised tool offers generic outbound network access (fetch_url, http_request, curl, wget, download, upload, …). A public network-fetch tool turns the MCP server into an open proxy and a SSRF pivot for any agent that connects to it.
{
"networkAccessTools": [
{
"toolName": "fetch_url",
"match": "url",
"source": "name"
}
]
}No tool name, description or input schema references obvious PII fields (email, phone, ssn, password, …). This is a governance prompt, not a security failure — many legitimate CRM, HR, and support servers handle PII by design and will trip the rule. The intent is to make the PII surface visible during review, not to block it. Treat a fail as 'document data minimization, retention, and access controls', not 'remove the tool'.
{
"piiTools": [
{
"toolName": "list_users",
"match": "email",
"source": "description"
}
]
}The MCP endpoint is reached over HTTPS. Plain HTTP allows trivial credential and prompt leakage on any shared network path.
The MCP endpoint completes a TLS handshake whose certificate validates against Node's CA store and matches the requested hostname. Untrusted, expired, or hostname-mismatched certificates are observable here even when the JSON-RPC handshake fails.
The negotiated TLS version is 1.2 or 1.3. TLS 1.0 and 1.1 are deprecated by RFC 8996 and have known cryptographic weaknesses; servers offering them broaden the attack surface for downgrade and padding-oracle attacks.
The HTTPS endpoint returns a `Strict-Transport-Security` header with a non-trivial `max-age`. HSTS prevents trivial downgrade attacks by instructing user agents to refuse plain HTTP for the host going forward.
The MCP `tools/list` call returned an array (possibly empty) rather than failing. This is a precondition for the rest of the tool-surface evaluation and a baseline indicator that the server speaks MCP correctly.
The MCP `initialize` response includes a `protocolVersion`. Servers that omit it make safe client fallback impossible.
The `initialize` response includes a `serverInfo.name` so operators can recognize the implementation and cross-reference it with upstream advisories.
Every tool includes a non-empty `description`. Missing descriptions make capability review impossible without invoking the tool, which the scanner refuses to do.
The endpoint URL has no userinfo segment and no token-like keys (`token`, `api_key`, `apikey`, `access_token`, `refresh_token`, `password`, `secret`, `client_secret`) in its query string. Credentials in URLs leak through logs, Referer headers, browser history, and intermediary caches.
When the protected resource metadata advertises one or more authorization servers, at least one of those issuers publishes a parseable RFC 8414 / OpenID Connect Discovery metadata document. This is what tells a client where to send the user, where to fetch tokens, and where to verify signatures.
The advertised authorization server metadata does not advertise the resource owner password credentials grant or the implicit grant. Both are flagged as insecure by RFC 9700 and by OAuth 2.1, and should not appear on a modern authorization server.
What we did and did not look at.
The MCP endpoint returned 401 or 403 to an unauthenticated request.
Server returned a Bearer challenge.
A `/.well-known/oauth-protected-resource` document parsed successfully.
1 authorization server advertised by protected-resource metadata.
An authorization server advertised a `registration_endpoint` (RFC 7591). The scanner never POSTs to it — discoverability only.
Authorization-server metadata advertised: authorization_code, refresh_token.
Authorization-server metadata advertised a `token_endpoint`.
Authorization-server metadata advertised a `jwks_uri`.
Initialize, tools/list and most tool metadata were retrieved. The score is based on a complete protocol read.
Server responded to the initialize handshake.
Server advertised an MCP protocol version.
Server advertised serverInfo.name.
Enumerated the advertised tool surface.
8 tools advertised.
6 of 8 tools declare an input schema. 2 missing schemas.
8 of 8 tools include a description.
Never invoked by design. AgentReserve does not execute tools — safety is a structural invariant of the probe client.
Auth flows, token handling and permission boundaries were not exercised.
Server implementation, dependencies and supply chain were not audited.
No tool was executed, so side effects, latency, errors and rate limits were not observed.
What this report does not tell you
How this server has scored over time.