Click on "Install 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., "@Reqable MCP Server generate python code for the last POST request to the login 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.
Reqable MCP Server exposes local Reqable capture traffic to MCP clients (Windsurf/Cursor/Claude/Codex).
Default architecture is local-only:
Reqable posts HAR(JSON) to http://127.0.0.1:18765/report.
Optional incremental WebSocket events can be posted to http://127.0.0.1:18765/ws/events.
reqable-mcp normalizes and stores requests/messages in local SQLite.
MCP tools query local data only (no cloud relay by default).
Local-first, privacy-first ingest path.
Real-time ingest via Reqable Report Server.
HAR file import fallback for missed sessions.
HTTP request query/search/domain stats/API analysis.
WebSocket session/message parsing for HAR entries carrying message-frame extensions.
Cross-platform runtime (macOS / Linux / Windows with Python 3.10+).
Related MCP server: ProxyPin MCP Server
Install and open Reqable.
Configure Reqable Report Server to post to http://127.0.0.1:18765/report.
Ensure Node.js (for npx) and uv (for uvx) are available.
npx -y reqable-mcp@latestuv run reqable-mcp{
"mcpServers": {
"reqable": {
"command": "npx",
"args": ["-y", "reqable-mcp@latest"]
}
}
}Use these values in Reqable "Add Report Server":
Name: reqable-mcp-local
Match rule: * (or your target domains)
Server URL: http://127.0.0.1:18765/report
Compression: None (or keep consistent with your receiver)
After saving, generate traffic and call ingest_status to verify incoming payload count.
Important note: reqable-mcp still uses HTTP-only ingest transport (no native ws:// listener), but now supports two HTTP ingest paths: /report for HAR/session payload and /ws/events for incremental WebSocket events. WebSocket capture works when Reqable payload includes frame data (for example _webSocketMessages or event frame objects). Raw entry JSON and raw message JSON are preserved and exposed by WebSocket tools. HAR export/import remains the fallback when live pushes miss frames.
ingest_status: ingest server state and counters
import_har: import HAR from file path
list_requests: list recent HTTP/WebSocket handshake requests with filters
get_request: fetch request details by ID (full includes raw_entry)
search_requests: keyword search in HTTP URL/body/raw uploaded entry (raw / raw_entry)
list_websocket_sessions: list captured WebSocket sessions
list_active_websocket_sessions: list recently active WebSocket sessions by latest captured frames
get_websocket_session: fetch WebSocket session details and messages by ID (including raw_entry and message raw)
tail_websocket_messages: incremental fetch by request_id + after_seq cursor
search_websocket_messages: precise WebSocket message search by keyword, direction, type, opcode, close code, domain, and request ID
analyze_websocket_session: summarize directions, message types, JSON shapes, and close events for a session
export_websocket_session_raw: export the raw uploaded WebSocket entry and raw frame list
health_report: ingest status + WebSocket data quality report
repair_websocket_messages: backfill missing fields from raw frames (supports dry-run)
get_domains: domain-level request statistics
analyze_api: infer API shapes for a domain
generate_code: generate sample client code from captured HTTP request
Variable | Description | Default |
| Report receiver host |
|
| Report receiver port |
|
| Report receiver path |
|
| Incremental WebSocket event receiver path |
|
| Local data directory | platform app data dir |
| SQLite file path |
|
| Max persisted body bytes per request/message |
|
| Max accepted report payload bytes |
|
| Max HAR import file bytes |
|
| Local retention window |
|
| Optional local auth token | unset |
Data stays on local machine in default mode.
Retention cleanup is applied to local DB records, including WebSocket messages.
If ingest server is offline, Reqable failed report push is not retried.
MIT
Analyze API structure for a specific domain.
| Name | Required | Description | Default |
|---|---|---|---|
| domain | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states the tool analyzes API structure but does not reveal if it's read-only, destructive, requires authentication, has rate limits, or what the analysis entails (e.g., returns a report, modifies data). This leaves significant gaps in understanding its behavior and safety.
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?
The description is a single, clear sentence with no wasted words, making it highly concise and front-loaded. It directly states the tool's purpose without unnecessary elaboration, earning full marks for efficiency.
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?
Given the tool has 1 parameter, no annotations, and an output schema (which reduces the need to describe return values), the description is minimally adequate. However, it lacks details on analysis scope, behavioral traits, and parameter meaning, making it incomplete for informed use despite the output schema's assistance.
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 input schema has 1 parameter with 0% description coverage, and the tool description does not add any semantic details about the 'domain' parameter. It does not explain what a domain is (e.g., URL, name, identifier), format expectations, or examples, failing to compensate for the low schema coverage.
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 the tool's purpose as 'Analyze API structure for a specific domain,' which includes a verb ('analyze') and resource ('API structure'), making it clear what it does. However, it lacks specificity about what 'analyze' entails (e.g., endpoints, schemas, security) and does not differentiate from siblings like 'get_domains' or 'search_requests,' leaving it vague in comparison.
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 description provides no guidance on when to use this tool versus alternatives. It does not mention prerequisites, context (e.g., after importing data), or exclusions, nor does it reference sibling tools like 'get_domains' for domain listing or 'search_requests' for request analysis, offering no usage direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Analyze a WebSocket session and summarize frame directions, types, JSON shapes, and close events.
| Name | Required | Description | Default |
|---|---|---|---|
| request_id | Yes | ||
| sample_limit | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the tool analyzes and summarizes WebSocket sessions but does not cover critical aspects like whether it's read-only or mutative, permission requirements, rate limits, error handling, or output format details. For a tool with no annotation coverage, this is a significant gap in transparency.
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?
The description is a single, efficient sentence that front-loads the core action ('Analyze a WebSocket session') and details the analysis scope without unnecessary words. Every part of the sentence contributes directly to understanding the tool's function, making it highly concise and well-structured.
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?
Given the tool's complexity (analyzing WebSocket sessions with 2 parameters) and the presence of an output schema (which likely covers return values), the description is minimally adequate. It states what the tool does but lacks details on behavior, usage context, and parameter meanings. With no annotations and incomplete parameter documentation, it falls short of being fully complete for effective agent use.
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 description adds no information about parameters beyond what the input schema provides. With 0% schema description coverage, the parameters 'request_id' and 'sample_limit' are undocumented in both the schema and description. However, the description implies analysis of a session (hinting at 'request_id' usage) and summarization (suggesting 'sample_limit' might cap data), offering minimal contextual value. This meets the baseline for moderate schema coverage scenarios.
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 clearly states the tool's purpose: 'Analyze a WebSocket session and summarize frame directions, types, JSON shapes, and close events.' It specifies the verb ('analyze'), resource ('WebSocket session'), and scope of analysis (frame directions, types, etc.). However, it does not explicitly differentiate from sibling tools like 'get_websocket_session' or 'export_websocket_session_raw', which prevents a score of 5.
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 description provides no guidance on when to use this tool versus alternatives. It does not mention prerequisites (e.g., needing a valid request_id), exclusions, or comparisons to sibling tools such as 'get_websocket_session' (which might retrieve raw data) or 'export_websocket_session_raw' (which might export data). This lack of contextual direction limits its utility for an AI agent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Export the raw uploaded WebSocket session entry and raw frame list.
| Name | Required | Description | Default |
|---|---|---|---|
| request_id | Yes | ||
| include_normalized | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
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 mentions 'Export' but doesn't disclose behavioral traits such as whether this is a read-only operation, if it requires specific permissions, what the output format is, or any rate limits. This leaves significant gaps for a tool that likely involves data retrieval or processing.
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?
The description is a single, efficient sentence that front-loads the key action and resource without any wasted words. It's appropriately sized for the tool's apparent complexity, making it easy to parse quickly.
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?
Given that an output schema exists, the description doesn't need to explain return values. However, with no annotations, 0% schema coverage, and two parameters, the description is too minimal—it lacks context on usage, parameters, and behavior, making it incomplete for effective tool invocation despite the output schema.
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 0%, so the description must compensate. It adds no meaning beyond the schema, failing to explain what 'request_id' refers to (e.g., an identifier for a WebSocket session) or what 'include_normalized' does (e.g., whether it adds processed data to the raw export). This results in inadequate parameter clarification.
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 clearly states the action ('Export') and the resource ('raw uploaded WebSocket session entry and raw frame list'), making the purpose understandable. However, it doesn't explicitly differentiate from sibling tools like 'get_websocket_session' or 'list_websocket_sessions', which might retrieve similar data in different formats or scopes, so it falls short of a perfect score.
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 description provides no guidance on when to use this tool versus alternatives. With siblings like 'get_websocket_session' and 'analyze_websocket_session', it's unclear if this is for raw data export versus processed analysis or retrieval, leaving the agent without context for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Generate API call code from a captured request.
| Name | Required | Description | Default |
|---|---|---|---|
| request_id | Yes | ||
| language | No | python | |
| framework | No | requests |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the action ('generate') but doesn't explain what this entails—e.g., whether it's a read-only operation, if it requires specific permissions, what the output format is, or any rate limits. The description is too vague to inform the agent about behavioral traits beyond the basic purpose.
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?
The description is a single, efficient sentence: 'Generate API call code from a captured request.' It's front-loaded with the core purpose and contains no wasted words, making it highly concise and well-structured for quick understanding.
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?
Given the tool's moderate complexity (3 parameters, no annotations, but with an output schema), the description is incomplete. It states the purpose but lacks usage guidelines, parameter semantics, and behavioral context. The presence of an output schema means return values are documented elsewhere, but the description doesn't provide enough context for effective tool invocation without additional information.
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 0%, meaning parameters are undocumented in the schema. The description adds no semantic details about parameters like 'request_id', 'language', or 'framework'—it doesn't explain what a 'request_id' refers to, what languages are supported, or how the framework influences code generation. This fails to compensate for the low coverage, leaving parameters largely unexplained.
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 clearly states the tool's purpose: 'Generate API call code from a captured request.' It specifies the verb ('generate'), resource ('API call code'), and source ('captured request'), making the function unambiguous. However, it doesn't distinguish this tool from siblings like 'analyze_api' or 'export_websocket_session_raw', which might also involve code or request handling, so it misses full differentiation.
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 description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., needing a captured request via tools like 'get_request' or 'list_requests'), exclusions, or comparisons to siblings such as 'analyze_api' for analysis instead of code generation. This leaves the agent with minimal context for tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get all captured domains with request counts.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It mentions 'captured domains with request counts', hinting at read-only data retrieval, but lacks details on permissions, rate limits, data freshness, or output format. This is insufficient for a tool with no annotation support.
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?
The description is a single, efficient sentence that directly states the tool's function without any fluff. It's front-loaded and wastes no words, making it highly concise and well-structured.
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?
Given the tool's simplicity (0 parameters, output schema exists), the description is adequate but incomplete. It covers the basic purpose but lacks behavioral context needed due to missing annotations, making it only minimally viable for the agent's understanding.
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 has 0 parameters with 100% schema description coverage, so no parameter information is needed. The description doesn't add param details, which is appropriate, earning a baseline score above 3 due to the lack of parameters.
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 clearly states the verb 'Get' and the resource 'all captured domains with request counts', making the purpose specific and understandable. However, it doesn't explicitly differentiate from sibling tools like 'list_requests' or 'search_requests', which might also involve domain-related operations, so it falls short of a perfect score.
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 description provides no guidance on when to use this tool versus alternatives. With siblings like 'list_requests' and 'search_requests' that might overlap in domain handling, there's no explicit or implied context for selection, leaving the agent without usage direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get detailed information for a single request.
| Name | Required | Description | Default |
|---|---|---|---|
| request_id | Yes | ||
| include_body | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the tool retrieves 'detailed information,' implying a read-only operation, but doesn't clarify aspects like authentication requirements, rate limits, error handling, or what 'detailed information' includes. For a tool with no annotation coverage, this is a significant gap in transparency.
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?
The description is a single, clear sentence with no wasted words. It's front-loaded with the core purpose ('Get detailed information for a single request'), making it easy to parse. Every part of the sentence earns its place by conveying essential information efficiently.
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?
Given the tool's moderate complexity (2 parameters, no annotations, but with an output schema), the description is minimally adequate. The output schema reduces the need to explain return values, but the description lacks details on usage context, parameter meanings, and behavioral traits. It meets a basic threshold but has clear gaps in completeness.
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 0%, so the schema provides no parameter descriptions. The tool description mentions 'detailed information' but doesn't explain the parameters (request_id, include_body) or their semantics. However, with only 2 parameters and an output schema present, the baseline is 3, as the description doesn't add value beyond the schema but also doesn't compensate for the coverage gap.
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 clearly states the tool's purpose: 'Get detailed information for a single request.' It specifies the verb ('Get') and resource ('a single request'), making it easy to understand what the tool does. However, it doesn't explicitly differentiate from sibling tools like 'list_requests' or 'search_requests', which would require a 5.
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 description provides no guidance on when to use this tool versus alternatives. It doesn't mention sibling tools like 'list_requests' (for multiple requests) or 'search_requests' (for filtered searches), nor does it specify prerequisites such as needing a specific request_id. This leaves the agent without context for tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get WebSocket session details and messages by request ID.
| Name | Required | Description | Default |
|---|---|---|---|
| request_id | Yes | ||
| include_messages | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the tool retrieves details and messages, implying a read-only operation, but doesn't cover aspects like authentication needs, rate limits, error handling, or what 'details' include. For a tool with zero annotation coverage, this is a significant gap in transparency.
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?
The description is a single, efficient sentence that front-loads the core purpose without unnecessary words. Every part ('Get WebSocket session details and messages by request ID') earns its place by specifying key elements, making it appropriately sized and structured.
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?
Given the tool has an output schema, the description doesn't need to explain return values. However, with 2 parameters, 0% schema coverage, and no annotations, the description is minimal. It covers the basic purpose but lacks details on usage, behavior, and parameter semantics, making it adequate but with clear gaps for a retrieval tool.
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 0%, so the description must compensate. It mentions 'by request ID', which maps to the 'request_id' parameter, and 'messages', which relates to 'include_messages'. However, it doesn't explain parameter meanings beyond this basic mapping, such as what 'request_id' refers to or the implications of 'include_messages'. With low coverage, the description adds some value but doesn't fully compensate.
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 clearly states the tool's purpose: 'Get WebSocket session details and messages by request ID.' It specifies the verb ('Get'), resource ('WebSocket session details and messages'), and key identifier ('by request ID'). However, it doesn't explicitly differentiate from siblings like 'list_websocket_sessions' or 'analyze_websocket_session', which would require a 5.
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 description provides no guidance on when to use this tool versus alternatives. It doesn't mention siblings like 'list_websocket_sessions' for listing sessions or 'analyze_websocket_session' for analysis, nor does it specify prerequisites or exclusions. Usage is implied by the purpose but not explicitly stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Return ingest status plus data quality checks for WebSocket payloads.
| Name | Required | Description | Default |
|---|---|---|---|
| detail | No | ||
| sample_limit | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It mentions returning ingest status and data quality checks, but doesn't disclose behavioral traits like whether this is a read-only operation, if it requires specific permissions, rate limits, or what the output format looks like. The description is minimal and lacks essential operational context.
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?
The description is a single, efficient sentence with zero wasted words. It's appropriately sized for a simple tool and front-loads the core purpose without unnecessary elaboration.
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?
Given the tool's moderate complexity (2 parameters, output schema exists), the description is incomplete. While the output schema may cover return values, the description lacks parameter explanations and behavioral context. It provides a basic purpose but doesn't fully equip an agent to use the tool effectively without relying heavily on schema inspection.
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 0%, so the description must compensate for undocumented parameters. It provides no information about the two parameters ('detail' and 'sample_limit'), their purposes, or how they affect the returned health report. The description fails to add any parameter semantics beyond the bare 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?
The description clearly states the tool's purpose with a specific verb ('Return') and resource ('ingest status plus data quality checks for WebSocket payloads'). It distinguishes itself from siblings like 'ingest_status' by adding data quality checks, but doesn't explicitly contrast with all relevant siblings like 'analyze_websocket_session' or 'repair_websocket_messages'.
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 guidance is provided on when to use this tool versus alternatives. With siblings like 'ingest_status', 'analyze_websocket_session', and 'repair_websocket_messages', the description lacks context about when this health report is appropriate versus other analysis or repair tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Import a HAR file (or line-delimited JSON entries) as fallback.
| Name | Required | Description | Default |
|---|---|---|---|
| file_path | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It states the tool imports data but doesn't disclose behavioral traits like whether this overwrites existing data, requires specific file formats beyond HAR/JSON, has rate limits, or what happens on success/failure. The 'as fallback' hint is vague and doesn't clarify the tool's role.
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?
The description is a single, efficient sentence with no wasted words. It's appropriately sized for a simple tool and front-loads the core action ('Import a HAR file').
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?
Given 1 parameter with 0% schema coverage and an output schema exists, the description is minimally adequate. It covers the basic purpose but lacks details on usage context, behavioral implications, and parameter specifics. The output schema reduces the need to explain return values, but more guidance would help.
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 0%, so the description must compensate. It mentions 'HAR file (or line-delimited JSON entries)' which adds some context about the file_path parameter's expected content, but doesn't specify format details, constraints, or examples. This partially compensates but leaves significant gaps.
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 the tool imports a HAR file or line-delimited JSON entries, which is a clear verb+resource combination. However, it doesn't differentiate from sibling tools like 'analyze_api' or 'ingest_status' that might also handle data ingestion, and the 'as fallback' phrase is ambiguous without context.
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 description provides no guidance on when to use this tool versus alternatives. It mentions 'as fallback' but doesn't explain what it's a fallback for or when other tools like 'ingest_status' or 'analyze_api' should be preferred. There are no explicit when/when-not instructions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Check local ingest server status.
| Name | Required | Description | Default |
|---|---|---|---|
| auto_start | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure but only states the basic action. It doesn't reveal whether this is a read-only operation, if it requires authentication, what the output format is, or any rate limits. The presence of an output schema helps, but the description itself adds minimal behavioral context beyond the core function.
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?
The description is extremely concise at just one sentence with no wasted words. It's front-loaded with the core purpose and uses clear, direct language that makes the tool's function immediately apparent without unnecessary elaboration.
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?
Given the tool's simplicity (one optional parameter) and the presence of an output schema, the description is minimally adequate. However, with no annotations and multiple sibling tools including 'health_report', the description should ideally provide more context about how this differs from other status/monitoring tools to be fully complete.
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 description doesn't mention parameters, but with only one optional parameter (auto_start) and 0% schema description coverage, this is acceptable. For a single parameter tool, the description focusing on the tool's purpose rather than parameter details is reasonable, though it doesn't explain what 'auto_start' means in context.
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 clearly states the action ('Check') and resource ('local ingest server status'), making the tool's purpose immediately understandable. However, it doesn't differentiate this status check from other monitoring tools like 'health_report' among the siblings, which would require explicit comparison to earn a perfect score.
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 description provides no guidance on when to use this tool versus alternatives like 'health_report' or other sibling tools. It lacks any context about prerequisites, timing, or scenarios where this specific status check is appropriate, leaving the agent without usage direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List recently active WebSocket sessions inferred from latest captured frames.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| domain | No | ||
| active_within_seconds | No | ||
| include_closing | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden but offers minimal behavioral insight. It mentions sessions are 'inferred from latest captured frames', hinting at data source limitations, but doesn't cover permissions, rate limits, side effects, or response format. More detail is needed for a mutation-free tool with zero annotation coverage.
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?
The description is a single, efficient sentence with no wasted words. It front-loads the core purpose and includes a useful qualifier about inference, making it appropriately sized for the tool's complexity.
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?
Given 4 parameters with 0% schema coverage, no annotations, but an output schema exists, the description is moderately complete. It covers the tool's purpose and data source but lacks parameter guidance, behavioral context, and sibling differentiation. The output schema mitigates some gaps, but more detail is needed for full understanding.
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 0%, so the description must compensate but adds no parameter-specific information. It implies recency ('recently active') which loosely relates to 'active_within_seconds', but doesn't explain parameters like 'limit', 'domain', or 'include_closing'. Baseline 3 is given as the schema itself provides structure, but the description adds minimal value.
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 clearly states the action ('List') and resource ('recently active WebSocket sessions'), with additional context about how sessions are inferred ('from latest captured frames'). It distinguishes from the sibling 'list_websocket_sessions' by specifying 'active' sessions, though the distinction could be more 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?
No explicit guidance on when to use this tool versus alternatives like 'list_websocket_sessions' or 'analyze_websocket_session'. The description implies it's for recent activity, but lacks context on prerequisites, exclusions, or specific use cases compared to siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List recent HTTP/WebSocket handshake requests captured from Reqable reports.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| detail | No | summary | |
| domain | No | ||
| method | No | ||
| status | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the action ('List') and source ('captured from Reqable reports'), but lacks details on permissions, rate limits, pagination, or what 'recent' means. For a tool with 5 parameters and no annotation coverage, this is a significant gap.
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?
The description is a single, efficient sentence that directly states the tool's purpose without unnecessary words. It's appropriately sized and front-loaded with essential 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?
Given the tool has 5 parameters with 0% schema coverage, no annotations, and sibling tools that suggest complexity (e.g., 'search_requests'), the description is inadequate. It doesn't explain parameter usage, behavioral traits, or differentiation from alternatives, though the presence of an output schema reduces the need to describe return values.
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 0%, meaning none of the 5 parameters are documented in the schema. The description provides no information about parameters like 'limit', 'detail', 'domain', 'method', or 'status', failing to compensate for the schema's lack of documentation.
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 clearly states the verb ('List') and resource ('recent HTTP/WebSocket handshake requests captured from Reqable reports'), making the purpose specific and understandable. However, it doesn't explicitly differentiate from sibling tools like 'search_requests' or 'get_request', which appear to be related alternatives.
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 description provides no guidance on when to use this tool versus alternatives like 'search_requests' or 'get_request'. It mentions the resource scope but offers no context about appropriate use cases, exclusions, or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List captured WebSocket sessions.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| detail | No | summary | |
| domain | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden for behavioral disclosure. It only states the action ('List captured WebSocket sessions') without mentioning permissions, rate limits, pagination, or what 'captured' means in this context. This leaves significant gaps for a tool with 3 parameters.
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?
The description is a single, efficient sentence with no wasted words. It's appropriately sized for a basic listing tool and front-loads the core purpose immediately.
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?
The description is minimal but covers the basic purpose. With an output schema present, it doesn't need to explain return values. However, given 3 parameters with 0% schema coverage and no annotations, it should provide more context about usage and parameter effects to be fully complete.
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 0%, so the description must compensate by explaining parameters. It mentions no parameters at all, failing to clarify what 'limit', 'detail', or 'domain' mean or how they affect the listing. This is inadequate given the parameter count and lack of schema descriptions.
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 clearly states the verb ('List') and resource ('captured WebSocket sessions'), making the purpose immediately understandable. However, it doesn't differentiate from sibling tools like 'list_active_websocket_sessions' or 'get_websocket_session', which would require more specificity for a perfect score.
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 description provides no guidance on when to use this tool versus alternatives. With siblings like 'list_active_websocket_sessions' and 'get_websocket_session' available, there's no indication of what distinguishes this tool (e.g., listing all captured sessions vs. active ones only).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Backfill missing WebSocket message fields from raw frames.
| Name | Required | Description | Default |
|---|---|---|---|
| max_rows | No | ||
| dry_run | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions 'Backfill' which implies a write/mutation operation, but doesn't specify whether this is destructive, requires permissions, has side effects, or how it interacts with existing data. The mention of 'raw frames' adds some context, but key behavioral traits are missing.
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?
The description is a single, efficient sentence that gets straight to the point with no wasted words. It's appropriately sized for the tool's apparent complexity and front-loads the core purpose effectively.
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?
Given that there's an output schema (which handles return values) and only 2 parameters, the description is somewhat complete for a basic tool. However, as a mutation tool with no annotations, it should provide more context about behavioral implications and usage scenarios to be fully complete.
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 description doesn't mention any parameters, while the schema has 2 parameters with 0% description coverage. Since schema_description_coverage is 0%, the description should compensate but doesn't explain what 'max_rows' or 'dry_run' mean in this context. The baseline is 3 because there are only 2 parameters, but the description adds no value 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?
The description clearly states the action ('Backfill') and target resource ('missing WebSocket message fields from raw frames'), providing a specific verb+resource combination. However, it doesn't explicitly differentiate from sibling tools like 'search_websocket_messages' or 'tail_websocket_messages', which prevents a perfect score.
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 description provides no guidance on when to use this tool versus alternatives like 'search_websocket_messages' or 'tail_websocket_messages', nor does it mention prerequisites or context for when backfilling is appropriate. It only states what the tool does, not when to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search requests by keyword in URL, bodies, or raw uploaded entry (raw / raw_entry).
| Name | Required | Description | Default |
|---|---|---|---|
| keyword | Yes | ||
| search_in | No | all | |
| limit | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It mentions what fields are searched but doesn't describe the search behavior (exact match, partial, case-sensitive), pagination (though limit parameter exists), return format, or performance characteristics. For a search tool with zero annotation coverage, this leaves significant behavioral gaps.
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?
The description is a single, efficient sentence that communicates the core functionality without waste. It's appropriately sized for a search tool and front-loads the essential information. Every word contributes to understanding what the tool does.
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?
Given the tool has an output schema (which handles return values), 3 parameters with 0% schema coverage, and no annotations, the description provides basic purpose but lacks behavioral context, parameter details, and usage guidance. It's minimally adequate but leaves the agent to infer too much about how to effectively use this search tool.
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 0%, so the schema provides no parameter descriptions. The description mentions 'keyword' and implies 'search_in' by listing searchable fields, but doesn't explain parameter meanings, defaults, or constraints. It partially compensates for the coverage gap but leaves 'limit' undocumented. Baseline 3 is appropriate as it adds some value but doesn't fully document all parameters.
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 clearly states the tool searches requests using keywords and specifies the searchable fields (URL, bodies, raw uploaded entry). It distinguishes from siblings like 'list_requests' by indicating a keyword-based search rather than simple listing. However, it doesn't explicitly contrast with 'search_websocket_messages' which might have similar search functionality for a different resource type.
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 description provides no guidance on when to use this tool versus alternatives like 'list_requests' or 'search_websocket_messages'. It doesn't mention prerequisites, performance considerations, or any 'when-not-to-use' scenarios. The agent must infer usage from the purpose alone without explicit direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search WebSocket messages by keyword and precise frame filters.
| Name | Required | Description | Default |
|---|---|---|---|
| keyword | No | ||
| direction | No | ||
| message_type | No | ||
| opcode | No | ||
| request_id | No | ||
| domain | No | ||
| close_code | No | ||
| has_json | No | ||
| limit | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure but offers minimal information. It mentions searching by keyword and frame filters but doesn't describe what the search returns, whether it's paginated, what permissions are needed, or any rate limits. For a search tool with 9 parameters and no annotation coverage, this is inadequate.
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?
The description is extremely concise - a single sentence that directly states the tool's core function. There's no wasted language or unnecessary elaboration, making it efficient and front-loaded.
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?
Given the tool's complexity (9 parameters, no annotations, but has an output schema), the description is incomplete. While the output schema may document return values, the description doesn't address key behavioral aspects like search scope, result format, or usage context. It's minimally adequate but leaves significant gaps for a search operation.
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?
With 0% schema description coverage for all 9 parameters, the description fails to compensate for this gap. It mentions 'keyword and precise frame filters' which hints at some parameters (keyword, direction, message_type, opcode, etc.) but doesn't explain what these filters mean, their valid values, or how they interact. The description adds minimal value beyond what's already implied by parameter names.
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 clearly states the tool's purpose as searching WebSocket messages with keyword and frame filters, which is a specific verb+resource combination. However, it doesn't explicitly differentiate from sibling tools like 'search_requests' or 'tail_websocket_messages', which appear to be related search/filtering operations.
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 description provides no guidance on when to use this tool versus alternatives. With sibling tools like 'search_requests', 'tail_websocket_messages', and 'list_websocket_sessions' available, there's no indication of when this specific search tool is appropriate versus those other options.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Tail WebSocket messages for one session using seq cursor.
| Name | Required | Description | Default |
|---|---|---|---|
| request_id | Yes | ||
| after_seq | No | ||
| direction | No | ||
| message_type | No | ||
| include_raw | No | ||
| limit | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It mentions 'tail' and 'seq cursor', hinting at streaming or paginated behavior, but doesn't disclose critical traits: whether this is a read-only operation, if it streams real-time data, rate limits, authentication needs, or what happens when the session ends. The description adds minimal behavioral context beyond the tool name.
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?
The description is a single, efficient sentence with zero waste. It's front-loaded with the core action ('Tail WebSocket messages') and includes the key constraint ('for one session using seq cursor'). Every word earns its place, making it highly concise and well-structured for its brevity.
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?
Given the complexity (6 parameters, 0% schema coverage, no annotations) and the presence of an output schema, the description is incomplete. It doesn't explain the tool's behavior, parameter usage, or relationship to siblings. While the output schema might cover return values, the description lacks essential context for a tool with multiple parameters and no annotation support, making it inadequate for informed use.
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 0%, so the description must compensate. It only references 'seq cursor' (likely related to 'after_seq'), ignoring the other 5 parameters (request_id, direction, message_type, include_raw, limit). No additional meaning is provided for any parameter, leaving semantics unclear. This fails to address the coverage gap adequately.
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 the tool 'tails WebSocket messages for one session using seq cursor', which provides a basic verb+resource combination ('tail' + 'WebSocket messages'). However, it's vague about what 'tail' means in this context (real-time streaming? historical retrieval?), and it doesn't differentiate from sibling tools like 'search_websocket_messages' or 'get_websocket_session'. The purpose is understandable but lacks specificity.
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 guidance is provided on when to use this tool versus alternatives. The description doesn't mention sibling tools like 'search_websocket_messages' or 'list_websocket_sessions', nor does it specify prerequisites or contexts (e.g., for debugging, monitoring). Usage is implied through the 'seq cursor' reference but not explicitly stated, leaving the agent to infer from parameters alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Capture, inspect & debug HTTPS traffic across iOS, Android, browsers & backends — 304 MCP tools.
Read-only MCP server for The Quiet Protocol's engines, benchmarks, proof, and business data.
Agent-native MCP server over the public saagarpatel.dev corpus. Read-only, stateless.
Search your AI chat history (ChatGPT, Claude, Codex) from any MCP client. Remote, private, read-only
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/ElonJask/reqable-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
