What can you do with this server?

This server lets you make HTTP API requests and automatically capture request/response pairs as structured evidence files, proving that backend endpoints work correctly. It can also retrieve OTPs or verification codes from email. Core capabilities: * Start an evidence session (start_evidence_session): Initialize a named session with an optional baseUrl, creating a timestamped evidence directory (.evidence/ / /). Returns a sessionId for subsequent calls. * Make HTTP requests (request): Execute HTTP requests (GET, POST, PUT, PATCH, DELETE, HEAD, OPTIONS) with support for custom headers, request bodies, and optional labels. Full request/response pairs (status, headers, body, timing) are logged as evidence, with sensitive headers (authorization, cookie, api-key, etc.) automatically redacted before writing to disk. Relative URLs are resolved against the session's baseUrl. * Finish an evidence session (finish_evidence_session): Close a session and write two artifact files — requests.json (all request/response pairs) and manifest.json (summary with request and failure counts) — returning the evidence folder path. * Wait for email/OTP (wait_for_email): Poll an IMAP inbox to retrieve OTPs, verification codes, or magic links matching subject or content patterns. Operates independently of evidence sessions and requires IMAP configuration via environment variables. Additional notes: * Sessions auto-close after 10 minutes of inactivity, and open sessions are flushed on server shutdown. * The server is generic — point it at any API base URL. * Evidence files are intended to be stored locally and excluded from version control via .gitignore.

Which integrations are available for this server?

Provides IMAP-based email polling to retrieve OTP/verification codes from a Gmail inbox, supporting subject matching and regex pattern extraction.

How do I use mcp-evidence-api?

1. Click on "Install Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@mcp-evidence-api start an evidence session to test the create user endpoint" That's it! The server will respond to your query, and you can continue using it as needed. Here is a step-by-step guide with screenshots.

mcp-evidence-api

by meovan07

Overview Schema Related Servers Score Discussions

TypeScript

Local

mcp-evidence-api

An MCP server that makes backend/API requests and packages request+response pairs as evidence — proving an endpoint works. Sibling project to mcp-evidence, which does the same thing for browser/UI flows; this one is for testing backend behavior with no browser involved (video/trace don't mean anything without a page, so this is a separate, much simpler tool rather than an extension of that one).

Generic and reusable: no assumptions about any particular API. You pass a baseUrl per session, and evidence is written into the consuming project's working directory at .evidence/<featureName>/<timestamp>/.

Install

Register with Claude Code

Per-user (available in every project):

claude mcp add --scope user evidence-api -- npx -y github:meovan07/mcp-evidence-api

Or per-project, add to .mcp.json:

{
  "mcpServers": {
    "evidence-api": {
      "command": "npx",
      "args": ["-y", "github:meovan07/mcp-evidence-api"]
    }
  }
}

This repo is public, so no GitHub credentials are needed on the machine running npx.

Consuming projects should add .evidence/ to their own .gitignore.

Related MCP server: mcp-server-apidebug

Tools

Tool	Purpose
`start_evidence_session({ featureName, baseUrl? })`	Creates the evidence dir. Returns `sessionId`.
`request({ sessionId, name?, method, url, headers?, body? })`	Makes an HTTP request, logs the full request/response pair. `url` resolves against `baseUrl` if relative.
`query({ sessionId, name?, sql, params? })`	Runs a read-only SQL query against Postgres and logs it — see below.
`finish_evidence_session({ sessionId, summary? })`	Writes `requests.json`, `queries.json`, and `manifest.json`, returns request/failure/query counts.
`wait_for_email({ from?, subjectContains?, pattern?, timeoutMs?, pollIntervalMs? })`	Polls an IMAP inbox for a new email (e.g. an OTP/verification code) and returns it — see below. Independent of the evidence-session tools above; doesn't write anything to `.evidence/`.

A session left open for 10 minutes with no tool calls is auto-finished. The server also flushes any open sessions on SIGINT/SIGTERM so evidence isn't lost if the process is killed mid-run.

Sensitive request/response headers (authorization, cookie, set-cookie, x-api-key, api-key, x-auth-token, proxy-authorization) are redacted before being written to disk. This only covers header names — if an endpoint echoes a secret back inside a JSON response body, that isn't redacted, since there's no reliable way to tell a secret-looking field from a normal one. Don't point this at endpoints that echo credentials in response bodies without being aware evidence files will contain them in plaintext.

Example

start_evidence_session({ featureName: "users api", baseUrl: "http://localhost:4000" })
  -> sessionId, evidenceDir

request({ sessionId, name: "create user", method: "POST", url: "/users", body: { name: "Ada" } })
request({ sessionId, name: "get user", method: "GET", url: "/users/1" })
finish_evidence_session({ sessionId, summary: "Users API create+fetch works" })

Resulting evidence directory:

.evidence/users-api/2026-07-08T08-41-21-754Z/
  requests.json
  manifest.json

requests.json is an array of full request/response records (method, url, headers, body, status, timing). manifest.json is a summary: request count and how many came back non-2xx.

`query` (database verification)

An API response can claim an action succeeded without the database actually reflecting it correctly (soft-deletes, audit fields, related-table writes). query lets you check the real state directly — currently Postgres only.

Setup: set DATABASE_URL as an environment variable on the MCP server registration, same pattern as the IMAP credentials — run this yourself, don't have an agent run it or inspect it afterward:

claude mcp add --scope user evidence-api \
  -e DATABASE_URL=postgres://user:password@host:5432/dbname \
  -- npx -y github:meovan07/mcp-evidence-api

Read-only, enforced twice: input is rejected unless it's a single SELECT/WITH ... SELECT statement (no semicolon-separated multi-statement tricks), and every query runs inside a database-level read-only transaction (SET SESSION CHARACTERISTICS AS TRANSACTION READ ONLY), so a write hidden inside something like a CTE — which could slip past the input check — still gets rejected by Postgres itself. Validated directly: a WITH deleted AS (DELETE ... RETURNING *) SELECT * FROM deleted attempt was rejected with cannot execute SELECT in a read-only transaction, and the row was confirmed still present afterward.

query({ sessionId, name: "confirm signup row", sql: "SELECT * FROM users WHERE email = $1", params: ["ada@example.com"] })
  -> "1 row(s) (2ms)\n[{\"id\":1,\"email\":\"ada@example.com\",...}]"

Results over 50 rows are truncated in the evidence file (the tool's response still reports the true rowCount); string cell values over 2000 characters are truncated too.

`wait_for_email` (OTP / verification-code retrieval)

For test flows that require an email OTP (signup, login, password reset). Reads over IMAP — no browser, no Gmail login automation, nothing that breaks when a mail provider's web UI changes.

Setup: requires an IMAP-accessible mailbox and an app password (Gmail: enable 2-Step Verification, then generate one at myaccount.google.com/apppasswords). Set these as environment variables on the MCP server registration — never commit them, never put them in a tracked file:

claude mcp add --scope user evidence-api \
  -e IMAP_USER=you@gmail.com \
  -e IMAP_APP_PASSWORD=xxxxxxxxxxxxxxxx \
  -- npx -y github:meovan07/mcp-evidence-api

Run this yourself in your own terminal rather than having an agent run it — claude mcp get <name> echoes registered env vars back in plaintext, so credentials shouldn't pass through a session that might inspect it later.

(IMAP_HOST is optional, defaults to imap.gmail.com.)

Behavior: only matches emails that arrive after the tool call starts (with a small clock-skew buffer), so it never accidentally picks up a stale OTP from an earlier run. Polls until a match or timeoutMs (default 30s) elapses, then throws a clear timeout error.

wait_for_email({ subjectContains: "verification code", pattern: "\\d{6}" })
  -> "Matched: 482913 (from email \"Your verification code\" sent by noreply@yourapp.com)"

If you don't pass pattern, it returns the full email (from/subject/date/body text) instead of trying to extract a code — useful for reading a magic link URL, for example.

Security notes: the app password should be scoped to nothing but this — generate one just for this purpose, and revoke it if you ever suspect it leaked. This tool only reads mail; it can't send, delete, or modify anything. The extracted code is returned as plain text in the tool result (by design — that's how you use it), so don't point this at a mailbox that receives anything more sensitive than test/verification emails.

Development

npm install
npm run build   # tsc -> dist/
npm run dev     # tsc --watch
npm start        # node dist/index.js

Available Tools

3 tools

finish_evidence_sessionFinish evidence sessionA

Writes requests.json (all request/response pairs) and manifest.json (summary + failure count), and returns the evidence folder path. Always call this at the end of a verification run.

ParametersJSON Schema

Name	Required	Description	Default
`summary`	No	Short human-readable summary of what was verified
`sessionId`	Yes

TDQS

A3.9/5.0

Behavior3/5

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

No annotations provided, so description must cover behavior. It discloses writing files and returning folder path, but lacks details on side effects (e.g., overwriting), failure conditions, or idempotency. Adequate but not thorough.

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?

Two sentences, front-loaded with core action, then usage directive. No superfluous text.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Without output schema, description gives only 'evidence folder path' as return. It doesn't detail error behavior, required permissions, or relationship to sibling tools beyond timing. Adequate for a simple finalize action but could add more context.

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

Parameters3/5

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

Schema covers 50% of parameters with descriptions. Description adds that summary goes into manifest.json and that requests.json contains request/response pairs, explaining summary's role. sessionId is not described beyond its name.

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 explicitly states it writes requests.json and manifest.json and returns the evidence folder path, distinguishing it from siblings request and start_evidence_session by indicating it is the final step.

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?

Clearly states 'Always call this at the end of a verification run', providing explicit when-to-use context. However, no guidance on when not to use or prerequisites like session existence.

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

requestRequestA

Makes an HTTP request and logs the full request/response pair (headers, body, status, timing) as evidence. Sensitive headers (authorization, cookie, api-key, etc.) are redacted before being written to disk. url may be relative to the session's baseUrl.

ParametersJSON Schema

Name	Required	Description
`url`	Yes
`body`	No	JSON-serializable request body
`name`	No	Short label for this request, for readability in the evidence file
`method`	Yes
`headers`	No
`sessionId`	Yes

TDQS

A3.5/5.0

Behavior3/5

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

Disclosures: logging, redaction of sensitive headers, relative URL. Missing: what the tool returns, error handling, authentication needs, or other side effects beyond logging. Annotations absent, so no contradiction.

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?

Two sentences, front-loaded with core action, additional detail in second sentence. No redundant or extraneous wording.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Missing important context: return value, error behavior, how to use parameters, relationship to evidence sessions. Insufficient for agent to call correctly with 6 params and no output schema.

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

Parameters2/5

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

Only 'url' is described (relative to baseUrl). Other parameters like 'sessionId', 'method', 'headers', 'body', 'name' lack explanation. With 33% schema coverage, description insufficiently compensates.

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?

Description clearly states the tool makes an HTTP request and logs the request/response as evidence. It distinguishes from sibling tools (session management) by specifying its unique function.

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?

Description mentions relative URL support but lacks explicit guidance on when to use versus alternatives or when not to use. No context on prerequisites or exclusions.

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

start_evidence_sessionStart evidence sessionA

Creates an evidence directory under .evidence/<featureName>/<timestamp>/ in the current project. Returns a sessionId to pass to request. Call finish_evidence_session when done.

ParametersJSON Schema

Name	Required	Description	Default
`baseUrl`	No	Base URL of the API under test; relative request() urls resolve against this
`featureName`	Yes	Short name for the API/backend feature being verified

TDQS

A4.2/5.0

Behavior3/5

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

No annotations provided; description explains side effect (creating directory) and path. Lacks details on permissions, idempotency, or failure modes, but covers basic behavior adequately.

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?

Two sentences with no wasted words. Front-loaded with action and resource, then return value and usage tips.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Covers creation, return value, and links to siblings. Could elaborate on session purpose, but given schema coverage and output schema absence, it's sufficiently complete.

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 covers both parameters with descriptions. Description adds value by clarifying baseUrl usage for url resolution, which is not obvious from schema alone. FeatureName explanation is minimal but acceptable.

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?

Description clearly states it creates an evidence directory with specific path, returns sessionId, and relates to sibling tools. Verb 'creates' and resource 'evidence directory' are explicit.

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?

Indicates when to use (start session) and references sibling tools: 'Call finish_evidence_session when done' and 'pass to request'. No explicit when-not-to-use, but context suffices.

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

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.

3 tool updatesv0.1.0Jul 8, 2026
- First observedfinish_evidence_session
- First observedrequest
- First observedstart_evidence_session

Install Server

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

TDQS

A4/5.0

Disambiguation5/5

Each tool has a distinct role: start session, make request, finish session. There is no overlap in functionality.

Naming Consistency4/5

Tools use snake_case with imperative verbs. 'request' is less descriptive but still follows the verb pattern; the other two follow verb_noun. Overall consistent.

Tool Count5/5

Three tools perfectly cover the session lifecycle: start, execute, finish. No redundancy or missing steps.

Completeness5/5

The toolset provides a complete workflow for recording HTTP evidence: session creation, request logging, and session finalization. No obvious gaps.

Maintenance

ActivitySlowing

ResponsivenessNo issues

Resources

GitHub Repository

Need Help?

Related Servers

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

Probe V0 A
io.github.lexbritten
Experimental MCP server for current empirical verification of explicit public HTTPS endpoint claims.
API Testing Penetration Testing
21
looptool
dev.looptool
An MCP server that automatically collects feedback on your MCP server.
Monitoring Developer Tools
2
clianythingharness-mcp
com.clauxel.clianythingharness
A paid remote MCP for CLI tool MCP, built to return verdicts, receipts, usage logs, and audit-ready
Command Line Monitoring
21
Swagger MCPOAuth
com.smartbear
MCP server for AI access to Swagger by SmartBear.
API Testing Documentation Access Developer Tools
144

Related MCP Servers

CyberMCP
API Testing Penetration Testing Security
ricauts
A
license
C
quality
D
maintenance
A Model Context Protocol server designed for testing backend APIs for security vulnerabilities like authentication bypass, injection attacks, and data leakage.
Updated a year ago (2025-05-28 05:19 UTC)
14
16
MIT
mcp-server-apidebug
API Testing Developer Tools
liliangshan
A
license
A
quality
D
maintenance
A standalone MCP server for API debugging, login authentication, API configuration management, and indexed API execution.
Updated 4 months ago (2026-04-28 04:08 UTC)
5
15
MIT
Postmancer
API Testing Developer Tools
hijaz
A
license
Not graded
quality
D
maintenance
A standalone MCP server for API testing and management, allowing AI assistants to interact with RESTful APIs through natural language.
Updated a year ago (2025-08-19 00:45 UTC)
23
28
MIT
api-mcp
Testing & QA Tools API Testing
Hassan-Jamal
A
license
A
quality
C
maintenance
An MCP server that automatically discovers API endpoints from any codebase, generates and runs tests, and produces per-role QA audit reports in PDF and XLSX.
Updated 2 months ago (2026-07-09 13:06 UTC)
10
753
MIT

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/meovan07/mcp-evidence-api'

If you have feedback or need assistance with the MCP directory API, please join our Discord server

mcp-evidence-api

Install

Register with Claude Code

Tools

Example

query (database verification)

wait_for_email (OTP / verification-code retrieval)

Development

Available Tools

Tool Schema Changelog

Maintenance

Resources

Looking for Admin?

Related MCP Connectors

Related MCP Servers

Latest Blog Posts

MCP directory API

`query` (database verification)

`wait_for_email` (OTP / verification-code retrieval)