Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@API Vault GET http://localhost:3000/health on our VPN and log why β smoke test"
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.
Local-first API Client & Model Context Protocol (MCP) Server powered by Node.js Native SQLite.
Zero cloud limits, zero data truncation, 100% private, with a high-density developer Web Studio.
Traditional cloud-based API clients (Postman, Hoppscotch Cloud) often hit painful ceilings:
Cloud Document Size Limits: E.g. Hoppscotch Cloud syncs user collections in a single Google Cloud Firestore document with a hard 1MB limit. Large OpenAPI specs, logs, or payload responses silently break sync (user/collection_creation_failed).
Privacy & Secret Leakage: Internal tokens, staging endpoints, and private corporate data end up on third-party cloud servers.
Disconnected AI Agents: When coding with Claude Desktop, Cursor, or Antigravity, AI agents cannot easily audit past requests or execute internal API queries without manual curl copying.
API Vault solves this permanently. Built entirely on Node.js 22+ native SQLite (node:sqlite) with zero external npm dependencies, API Vault stores gigabytes of full headers, input bodies, and raw responses locally on your machine, while seamlessly exposing an MCP interface to AI agents and a keyboard-friendly Web Studio for humans.
Related MCP server: RequestBin MCP Server
π Zero Size Limits & 100% Local Storage: Every request and response is persistently stored in ~/.api-vault/api_vault.db using Node.js native SQLite. No truncation, no cloud fees.
π€ Native MCP Server: Plug directly into Claude Desktop, Cursor, Antigravity, Cline, and any MCP client.
π Mandatory AI Purpose Logging: AI agents are required to declare why an endpoint is called (description), keeping an interpretable audit trail of all automated actions.
π₯οΈ Dense Tech Web Studio:
Collapsible Multi-Criteria Grouping: Group past requests by Host/Domain, Date, HTTP Status, Method, or Flat view.
Smart Endpoint Shortening: Automatically strips verbose schemes and hostnames, applying middle truncation (.../dags/demo/dagRuns) so you can identify resources at a glance.
One-Click Toggle (/api & β): Switch between compact paths and full URLs, or expand/collapse all groups instantly.
Hover Tooltips: Hover over any shortened endpoint to view the 100% complete URL.
π CORS-Free Execution Proxy: Call private VPN hosts, staging microservices, or local Docker services without browser CORS restrictions.
β‘ Zero Dependencies: Pure Node.js standard library (node:http, node:sqlite, node:child_process). Instant startup.
Run one command to start the local proxy and launch the Web Studio in your default browser:
npx api-vault studioOptions:
# Specify custom port (default: 54193)
npx api-vault studio -p 54193
# Specify custom SQLite data directory (default: ~/.api-vault)
API_VAULT_DATA_DIR=/path/to/data npx api-vault studioTo run API Vault as an MCP Stdio Server for your AI assistants:
npx api-vaultAdd this to your claude_desktop_config.json:
{
"mcpServers": {
"api-vault": {
"command": "npx",
"args": ["-y", "api-vault"]
}
}
}mcp.json){
"mcpServers": {
"api-vault": {
"command": "npx",
"args": ["-y", "api-vault"]
}
}
}mcp_config.json){
"mcpServers": {
"api-vault": {
"command": "node",
"args": ["/path/to/api-vault/src/server.js"],
"env": {
"API_VAULT_PORT": "54193"
}
}
}
}Tool | Description | Key Parameters |
| Execute an HTTP/REST/GraphQL request with unlimited SQLite audit logging. |
|
| Search historical requests by keyword, date, method, or HTTP status. |
|
| Retrieve full untruncated headers, request body, and response body by ID. |
|
| Get the live URL and status of the local Web Studio. | β |
| Export all stored requests into a clean JSON file. |
|
βββββββββββββββββββββββββββββββββββββββ
β AI Agent / MCP Client β
β (Claude Desktop, Cursor, Antigravity)β
ββββββββββββββββββββ¬βββββββββββββββββββ
β JSON-RPC (stdio)
βΌ
ββββββββββββββββββββββββ βββββββββββββββββββββββββββββββββββββββ
β Developer Browser β β API Vault Engine β
β (Dense Tech Studio) β β β
ββββββββββββ¬ββββββββββββ β β’ MCP Server (tools/call) β
β HTTP / SSE β β’ CORS Proxy Bridge β
βββββββββββββββββΊβ β’ Smart Truncation & Grouping β
ββββββββββββββββββββ¬βββββββββββββββββββ
β node:sqlite
βΌ
ββββββββββββββββββββββββ
β Local SQLite DB β
β (~/.api-vault/*.db) β
ββββββββββββββββββββββββMIT License Β© 2026 Vinh Tran. Free and open-source for personal and commercial use.
Execute an HTTP/REST/GraphQL request with unlimited audit logging into local SQLite database. Supports GET, POST, PUT, PATCH, DELETE, HEAD, OPTIONS. No size limits, 100% private.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | Target URL (supports http, https, private hosts, localhost) | |
| auth | No | Authentication configuration | |
| body | No | Request body (for POST, PUT, PATCH) | |
| title | No | Short semantic title for the request | |
| method | Yes | HTTP method | |
| headers | No | Request headers (key-value pairs) | |
| timeout | No | Timeout in milliseconds (default: 30000) | |
| description | Yes | MANDATORY: Business context and explicit purpose explaining why this request is called |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It does disclose two genuinely useful traits β every request is persisted to a local SQLite audit log (a durable side effect) and traffic stays local ('100% private') β but says nothing about whether mutating methods like DELETE take real effect, how auth failures surface, or what a response looks like.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences, front-loaded with the action and its persistence behavior. The trailing 'No size limits, 100% private' is slightly promotional but still carries operational information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For an 8-parameter tool with a nested auth object, no annotations, and no output schema, the description leaves real gaps: return value shape, error behavior, and how the auth variants (bearer/basic/api-key, header vs query) behave are undocumented anywhere. Adequate but incomplete for this complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents url, method, auth, headers, body, timeout, and the mandatory business-context field. The description only restates the method list (already an enum) and adds 'no size limits' for bodies; it adds no meaning for the nested auth object or timeout.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource β execute an HTTP/REST/GraphQL request β plus the side effect of audit logging to local SQLite. Sibling tools (search_history, get_request_detail) are clearly read-only history tools, so the executor role is distinguishable, though the description never names them explicitly.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is only implied: the tool is the way to make outbound calls, and the mention of audit logging hints that results are later visible via search_history, but no when-to-use/when-not-to-use conditions or alternatives are stated. An agent must infer the boundary itself.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Export all historical requests from local SQLite into a clean JSON file.
| Name | Required | Description | Default |
|---|---|---|---|
| file_path | No | Target JSON file path (default: ~/.api-vault/api_vault_export_<timestamp>.json) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full behavioral burden. It does disclose the source store (local SQLite) and the output artifact (JSON file), but says nothing about whether an existing file at file_path is overwritten, roughly how large an export can be, permissions needed, or what the call returns.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
One front-loaded sentence with zero filler; purpose, source, and output form arrive immediately. It is efficient, though the brevity trades away useful detail on the write-and-return behavior.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a one-parameter tool this covers the essentials, but with no output schema the description should say what comes back (e.g., written path or count) and whether existing files are replaced. Those gaps matter because the tool writes to disk.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and the single optional file_path parameter already documents its meaning and default path. The description adds no further semantics such as path format constraints or overwrite behavior, so the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource: export all historical requests into a JSON file, including the data source (local SQLite). It implicitly contrasts with search_history by emphasizing 'all' history rather than a filtered query, though it never names the sibling.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit when-to-use or when-not-to-use guidance. The word 'all' hints that this is the unfiltered bulk path versus search_history, but that inference is left entirely to the agent, and nothing is said about preconditions such as an existing history.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the link and connection info to the local API Vault Web Studio.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden, yet it says nothing about whether the call requires authentication, whether it fails when no local instance exists, or what 'connection info' contains. Only the word 'local' hints at behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single short sentence with no filler, front-loaded with the verb. It is under-specified rather than bloated, so size is fine.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description should explain what the returned link/connection info looks like and any conditions for success, but it does not. For a look-up tool an agent may need to chain into execute_request, this leaves the return contract opaque.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool takes zero parameters, so the baseline is 4; there is nothing for the description to disambiguate on the input side.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a retrieval verb and a resource ('the link and connection info to the local API Vault Web Studio'), but it conflates two things (a URL and connection info) without saying which is returned, and the name 'get_dashboard_url' doesn't match the 'Web Studio' wording. It does not distinguish itself from siblings such as execute_request or search_history.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no indication of when an agent should call this versus the sibling tools, no prerequisites (e.g., whether the Studio must be running locally), and no exclusions. The caller must infer its role entirely from the name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Retrieve complete audit details of a previous request by its ID (including 100% full headers, input body, and response body).
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | The ID of the request in the SQLite vault |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden; it does convey that this is a full-fidelity read returning headers and both bodies, and the '100%' phrasing hints at completeness versus any summarized view. It says nothing about permissions, behavior on a missing/nonexistent ID, size/truncation of large bodies, or whether the data is immutable.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
One front-loaded sentence with a tight parenthetical listing the returned fields; nothing is wasted. Slightly dense but easily parsed by an agent.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a one-parameter read-only lookup with no output schema, the description tells the agent what is returned (full headers, input body, response body), which is the main thing the absent output schema would have covered. Missing only edge-case behavior for invalid IDs.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and the single parameter is fully documented as 'The ID of the request in the SQLite vault'. The description only restates 'by its ID' and adds no format, sourcing, or validity constraints beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('Retrieve complete audit details of a previous request by its ID') and enumerates the payload (headers, input body, response body). It is clearly distinct from search_history by being an ID-based lookup, though it never names the sibling to make that contrast explicit.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied: use it once you already have a request ID from somewhere (e.g., search_history). There is no explicit statement of when to prefer this over search_history or export_history, and no mention of what to do if the ID is unknown.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search local SQLite API history by keyword, date, method, or HTTP status code.
| Name | Required | Description | Default |
|---|---|---|---|
| date | No | Filter by date (format: YYYY-MM-DD) | |
| limit | No | Max results to return (default: 50, max: 200) | |
| query | No | Keyword to search in URL, title, description, or response body | |
| method | No | Filter by HTTP method | |
| status_code | No | Filter by HTTP status code (e.g. 200, 404, 500) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. It usefully discloses that the data source is a local SQLite store (no network call, historical data only) and 'search' implies a read-only operation, but it says nothing about result ordering, matching semantics (substring vs token), or what a hit contains.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
One sentence, front-loaded with the action and resource, zero filler. Nothing could be removed without losing information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a five-parameter, all-optional read tool with a fully described schema and no output schema, this is nearly sufficient. The remaining gap is what a result record looks like and whether filters combine, but the schema handles most of the agent's needs.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all five parameters including formats and the default/max for limit. The description's enumeration of keyword, date, method, and status code merely restates the schema and omits limit and combination behavior (AND vs OR across filters).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Specific verb (search) plus resource (local SQLite API history) and the four filter dimensions. It is clearly distinct from execute_request and get_request_detail by virtue of being a search over stored history, though no sibling is named explicitly.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'search ... history' implies the retrieval use case, but there is no explicit when-to-use guidance, no mention of when to prefer get_request_detail for full payloads, and no note that export_history is the bulk alternative. Usage must be inferred from the name and description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v1.0.0execute_requestexport_historyget_dashboard_urlget_request_detailsearch_historyScored across 5 tools
Each tool has a clearly distinct role: execute a request, search history, retrieve one request by ID, get the dashboard URL, or export history. The only potential overlap is search_history vs get_request_detail, but the former lists/filters and the latter fetches full details by ID, so boundaries are clear.
All tool names use consistent snake_case with a clear verb_noun pattern. The slight length variation in get_request_detail and get_dashboard_url is natural and does not break consistency.
Five tools are well-scoped for an API request vault focused on execution, audit search, detail retrieval, export, and dashboard access. Each tool earns its place without obvious redundancy.
The surface covers the core lifecycle: execute requests, search audit history, inspect individual requests, export history, and access the web studio. Minor gaps include no replay/resend operation and no delete/clear-history operation, though these are not essential for the stated audit-focused purpose.
13 privacy-first network, auth & web tools for AI agents β no API key, 60 req/min free.
Reliable web access for AI agents: smart HTTP, rotating proxies, and full-browser rendering.
Durable memory, headless browser and research for agents. Pay per call: x402 USDC on Base or credits
Instant no-signup webhook & HTTP-request inspector for testing webhooks and agent tool-callbacks.
