Reqable MCP Server
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| REQABLE_DB_PATH | No | SQLite file path (defaults to ${REQABLE_DATA_DIR}/requests.db) | |
| REQABLE_DATA_DIR | No | Local data directory (defaults to platform app data dir) | |
| REQABLE_INGEST_HOST | No | Report receiver host | 127.0.0.1 |
| REQABLE_INGEST_PATH | No | Report receiver path | /report |
| REQABLE_INGEST_PORT | No | Report receiver port | 18765 |
| REQABLE_INGEST_TOKEN | No | Optional local auth token | |
| REQABLE_MAX_BODY_SIZE | No | Max persisted body bytes per request | 102400 |
| REQABLE_RETENTION_DAYS | No | Local retention window (days) | 7 |
| REQABLE_MAX_REPORT_SIZE | No | Max accepted report payload bytes | 10485760 |
| REQABLE_MAX_IMPORT_FILE_SIZE | No | Max HAR import file bytes | 104857600 |
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
} |
| prompts | {
"listChanged": false
} |
| resources | {
"subscribe": false,
"listChanged": false
} |
| experimental | {} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| ingest_statusB | Check local ingest server status. |
| health_reportC | Return ingest status plus data quality checks for WebSocket payloads. |
| import_harC | Import a HAR file (or line-delimited JSON entries) as fallback. |
| list_requestsC | List recent HTTP/WebSocket handshake requests captured from Reqable reports. |
| list_websocket_sessionsC | List captured WebSocket sessions. |
| list_active_websocket_sessionsB | List recently active WebSocket sessions inferred from latest captured frames. |
| get_requestB | Get detailed information for a single request. |
| get_websocket_sessionB | Get WebSocket session details and messages by request ID. |
| tail_websocket_messagesC | Tail WebSocket messages for one session using seq cursor. |
| search_requestsB | Search requests by keyword in URL, bodies, or raw uploaded entry ( |
| search_websocket_messagesC | Search WebSocket messages by keyword and precise frame filters. |
| repair_websocket_messagesB | Backfill missing WebSocket message fields from raw frames. |
| analyze_websocket_sessionB | Analyze a WebSocket session and summarize frame directions, types, JSON shapes, and close events. |
| export_websocket_session_rawC | Export the raw uploaded WebSocket session entry and raw frame list. |
| get_domainsB | Get all captured domains with request counts. |
| analyze_apiC | Analyze API structure for a specific domain. |
| generate_codeC | Generate API call code from a captured request. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
| startup_check_prompt |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
| recent_requests_resource | |
| websocket_sessions_resource | |
| websocket_active_resource | |
| domains_resource | |
| health_resource |
TDQS
Scored across 17 tools
Most tools have distinct purposes targeting specific resources like HTTP requests, WebSocket sessions, or data operations, with clear boundaries. However, some overlap exists between list_websocket_sessions and list_active_websocket_sessions, which could cause confusion in selection without careful reading of descriptions.
Tool names follow a highly consistent snake_case pattern with clear verb_noun structures throughout, such as analyze_api, get_request, list_requests, and search_websocket_messages. There are no deviations in naming conventions, making the set predictable and readable.
With 17 tools, the count is slightly high but reasonable for the server's scope in API and WebSocket analysis, covering ingestion, querying, and data management. It feels comprehensive without being overly bloated, though it borders on the heavy side for typical MCP servers.
The tool set provides complete coverage for the domain of API and WebSocket analysis, including ingestion (import_har, ingest_status), querying (list_requests, search_requests), detailed access (get_request, get_websocket_session), analysis (analyze_api, analyze_websocket_session), and data management (export, repair, tail). No obvious gaps are present, supporting full lifecycle workflows.