This MCP server enables AI assistants to perform automated API security audits, primarily detecting BOLA/IDOR vulnerabilities by executing requests with different user tokens and comparing responses.
Key capabilities:
Parse API specifications using parse_api_spec to read OpenAPI/Swagger files (JSON/YAML) and extract routes/methods.
Execute security requests with execute_security_request, supporting Bearer, Basic, API Key, and Cookie auth, plus anti-blocking features: rate limiting, stealth mode, User-Agent rotation, retries.
Detect authorization failures with analyze_access_control by comparing privileged vs unprivileged responses and flagging suspicious cases.
Manage session context via capture_context, get_context, list_context, and clear_context to store dynamic values for chained attacks.
Extract JSON values with extract_json_value using dot-notation to pull fields like resource IDs.
Record findings with save_security_finding, including severity, description, affected URL, and evidence.
Generate reports with generate_report (Markdown) and export_report_json (structured JSON).
Run full audits and chained attacks: create resources with one token, capture IDs, and attempt unauthorized access with another token; includes a vulnerable mock API for testing.
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., "@mcp-api-pentest check invoices endpoint for IDOR with admin and attacker tokens"
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.
An MCP server that lets AI assistants (Claude Desktop, Cursor, Claude Code) perform automated security audits on your APIs. It detects BOLA/IDOR vulnerabilities — the #1 risk in the OWASP API Top 10 — where one user can access another user's data.
Think of it as giving your AI the ability to act like a penetration tester, running requests with different user tokens and comparing the results to find broken authorization logic.
# 1. Clone and install
git clone https://github.com/josenieto/mcp-api-pentest
cd mcp-api-pentest
uv sync
# 2. Start the mock API (a vulnerable API for safe testing)
uv run mock_api.py
# 3. Start the MCP server
uv run app.pyThat's it. The server is now running and waiting for an AI client to connect.
Related MCP server: MCPPentestBOT
The project acts as a bridge between an AI and your API:
AI (Claude/Cursor) ←→ MCP Server ←→ API Target
|
Generates REPORTE_PENTEST.mdExample attack flow the AI can run:
Create an invoice with Token A → POST /api/v1/invoices
Read the same invoice with Token B → GET /api/v1/invoices/42
Detect the IDOR → both tokens return 200 OK with 94% similar content
Save the finding → "BOLA/IDOR in invoices endpoint — CRITICAL"
Generate a report → REPORTE_PENTEST.md
All of this happens without writing a single line of code — the AI drives the audit through MCP tools.
IDOR detection: Compares API responses with privileged vs unprivileged tokens
Chained attacks: Create a resource, capture its ID, then attack it with a different user
Multi-session state: Cache dynamic values across requests for complex attack flows
Smart truncation: Handles massive JSON responses without flooding the AI's context window
Rate limiting: Passive delays to avoid being blocked by WAFs
Intelligent retry: Detects 429 responses and retries with exponential backoff
Multiple auth schemes: Bearer, Basic, API Key (header/query), Cookie
Stealth mode: Random delay between requests to evade WAF detection patterns
User-Agent rotation: Rotates through a pool of realistic browser User-Agents
OpenAPI 3.x + YAML: Parses Swagger 2.0, OpenAPI 3.x in JSON or YAML format
Markdown reports: Automatic generation of security audit reports with evidence
Mock API sandbox: 9 intentionally vulnerable endpoints for safe testing
CLI entry point: Run from the terminal with mcp-api-pentest --target https://api.example.com
# 1. Start the mock API in the background
uv run mock_api.py &
sleep 2
# 2. Run a quick IDOR test
uv run python -c "
import anyio, json
from mcp_api_pentest.idor_detector.access_analyzer import analyze_access_control
async def test():
r = await analyze_access_control(
url='http://localhost:8080/api/v1/facturas/1001',
privileged_token='admin_secret_token_2026',
unprivileged_token='user_atacante_token_xyz',
delay_seconds=0,
)
print(json.loads(r)['idor_alert'])
result = anyio.run(test)
"After connecting the MCP server to Claude Desktop, Cursor, or Claude Code, paste these into your AI assistant:
Basic IDOR scan:
Audit the API at http://localhost:8080. Use the admin token 'admin_secret_token_2026' and the attacker token 'user_atacante_token_xyz'. Detect IDOR in all invoice endpoints.
Chained attack:
Create an invoice with the victim token 'user_victima_token_abc', capture its ID, then try to read and delete it with the attacker token 'user_atacante_token_xyz'.
Full audit with report:
Run a complete access control audit on http://localhost:8080. Test all endpoints with the three tokens: admin, victim, and attacker. Generate a findings report.
git clone https://github.com/josenieto/mcp-api-pentest
cd mcp-api-pentest
uv syncPython 3.10 or newer
uv package manager
Start the MCP server directly:
uv run app.pyWith options:
mcp-api-pentest \
--swagger spec.json \
--target https://api.example.com \
--token-admin "admin123" \
--token-victim "victim456" \
--token-attacker "attacker789" \
--output report.md \
--delay 1.0Add this to your MCP client configuration:
Claude Desktop (claude_desktop_config.json):
{
"mcpServers": {
"api-logic-pentest": {
"command": "uv",
"args": ["run", "app.py"],
"cwd": "/path/to/mcp-api-pentest"
}
}
}Cursor (.cursor/mcp.json):
{
"mcpServers": {
"api-logic-pentest": {
"command": "uv",
"args": ["run", "app.py"],
"cwd": "/path/to/mcp-api-pentest"
}
}
}Claude Code (~/.claude/mcp.json):
{
"mcpServers": {
"api-logic-pentest": {
"command": "uv",
"args": ["run", "app.py"],
"cwd": "/path/to/mcp-api-pentest"
}
}
}# Starts a vulnerable mock API on port 8080
uv run mock_api.pyThe mock API includes 3 test users with tokens:
User | Token | Role |
Admin |
| admin |
Victim |
| user |
Attacker |
| user |
Vulnerable endpoints (intentionally broken for testing):
GET /api/v1/facturas/{id} — IDOR (no ownership validation)
POST /api/v1/invoices — creates invoice, captures ID for chained attacks
DELETE /api/v1/invoices/{id} — deletes without ownership check
GET /api/v1/users/{id}/profile — reads profile without ownership check
PUT /api/v1/users/{id}/profile — mass assignment without ownership (escalate role to admin)
GET /api/v1/items — pagination without bounds validation
POST /api/v1/items — creates item for chained attacks
DELETE /api/v1/items/{id} — deletes without ownership check
GET /api/v1/spec.yaml — returns OpenAPI 3.x spec in YAML format
# Run all tests (141 tests, all passing)
uv run pytest
# Run with verbose output
uv run pytest -v
# Run tests for a specific module
uv run pytest src/mcp_api_pentest/idor_detector/tests/Code quality checks:
# Lint
uv run ruff check .
# Type checking
uv run mypy src/mcp_api_pentest/ --ignore-missing-importsThe AI can use 11 tools to audit APIs:
Tool | What it does |
| Reads an OpenAPI/Swagger file and extracts routes |
| Sends HTTP requests with auth headers and rate limiting |
| Compares responses from two tokens to detect IDOR |
| Stores a dynamic value (like a created ID) in memory |
| Retrieves a previously stored value |
| Lists all stored key-value pairs |
| Resets the session cache |
| Extracts a field from a JSON response using dot-notation |
| Records a security finding to the audit report |
| Returns the full Markdown audit report |
| Exports all findings as structured JSON |
This project follows a Modular Monolith by Features design.
src/mcp_api_pentest/
├── config/ → Global settings and logger
├── shared/ → Reusable utilities (JSON truncation)
├── spec_analyzer/ → OpenAPI/Swagger file parsing
├── http_client/ → HTTP communication with auth providers
├── idor_detector/ → Multi-session authorization comparison
├── audit_context/ → In-memory state for chained attacks
├── report_generator/ → Security finding reports (Markdown + JSON)
├── orchestration/ → Cross-module attack flow coordinator
└── adapters/ → Entry points: MCP server and CLIEach module is self-contained with its own tests. New detection patterns (like Mass Assignment or Rate Limit testing) are added as new modules without touching existing code.
See docs/adr/ADR-001-modular-monolith-by-features.md for the full architecture decision.
Create a branch from integration/master
Write your changes plus tests (we follow RED/GREEN/REFACTOR)
Push — CI runs lint, type check, and tests automatically
When CI passes, the merge happens automatically
MIT
Executes the same HTTP request with two different tokens (privileged vs unprivileged) and compares responses to detect authorization failures (BOLA/IDOR). Automatically cleans volatile fields (timestamps, session_ids, etc.) and calculates structural similarity. Marks as 'is_suspicious_success' if both return 200 OK with >85% similarity. When stealth mode is enabled, uses random delay to evade WAF detection patterns. Supports multiple auth types: bearer, basic, api_key_header, api_key_query, cookie.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | ||
| method | No | GET | |
| stealth | No | ||
| auth_type | No | bearer | |
| body_json | No | ||
| auth_key_name | No | ||
| delay_seconds | No | ||
| privileged_token | Yes | ||
| unprivileged_token | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description carries the full burden. It discloses the response comparison, volatile field cleaning, structural similarity calculation, the >85% threshold for suspicious success, stealth mode with random delays to evade WAF, and supported auth types. This is comprehensive behavioral disclosure.
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 focused paragraph that starts with the primary action and adds supporting details without fluff. Every sentence contributes to understanding the tool's function and 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?
The description covers the core purpose, the detection logic, and key configuration options. With an output schema present, return values need not be explained. Some parameters like body_json and auth_key_name are not elaborated, but overall it is sufficient for a human or agent to select and use the 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?
The schema has no descriptions, so the text must compensate. It explains the token comparison, auth types, stealth behavior, and delay, but leaves body_json and auth_key_name without additional context. It adds meaning beyond the raw schema for most parameters, but not all.
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 executes HTTP requests with two tokens and compares responses to detect authorization failures like BOLA/IDOR. This specific verb+resource+outcome distinguishes it from sibling tools such as execute_security_request or extract_json_value.
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 explains the exact scenario (comparing privileged vs unprivileged tokens) and the detection mechanism, implying when it should be used. However, it does not explicitly name alternatives or exclusion criteria, so it falls short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Stores a dynamic value in the session cache. Use after POST/PUT responses to save resource IDs for later use in DELETE/GET requests with a different auth token.
| Name | Required | Description | Default |
|---|---|---|---|
| key | Yes | ||
| value | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It reveals that values are dynamic, that it is used for storing resource IDs, and that the cache works across auth tokens. However, it does not disclose persistence semantics (memory vs. disk), expiration, overwrite behavior, or any security implications. The cross-token hint adds context but is not comprehensive.
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 two sentences, concise, and front-loaded with the primary action. Every word adds value: the verb, the object, and the usage context. There is no redundancy or filler.
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 simple two-parameter tool with an output schema, the description covers the core functionality and the critical usage scenario. It mentions the cross-auth-token behavior, which is significant. The main gap is that it doesn't mention edge cases like overwriting an existing key or cache scoping, but the output schema likely handles return values. Overall, it is reasonably complete for its 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 0%, so the description must compensate. It partially does by explaining that the value is a dynamic value often a resource ID, but it does not elaborate on the 'key' parameter's semantics, such as naming conventions or uniqueness constraints. Without explicit parameter-level guidance, the agent is left to infer from generic key-value patterns.
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 action ('Stores a dynamic value in the session cache') and specifies the exact use case (after POST/PUT responses to save resource IDs). It is distinguishable from sibling tools like get_context, list_context, and clear_context because it focuses on storing, not retrieving or clearing.
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 explicit guidance on when to use the tool: after POST/PUT responses and for later use in DELETE/GET requests. It also adds a valuable context note about using a different auth token. However, it does not mention situations where it should not be used or explicitly name alternatives, so it falls short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Clears all stored values from the session cache. Use at the start of a new audit cycle to avoid stale data contamination.
| 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 full burden. It discloses the destructive nature ('Clears all stored values') and the purpose, implying irreversibility. However, it does not explicitly mention side effects on other tools or lack of undo, but the main behavior is clearly stated.
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 with the action front-loaded. Every word earns its place, with no fluff or repetition.
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 zero-parameter, straightforward tool, the description fully conveys what it does and when to use it. An output schema exists, so return value details are not required. No additional context is needed.
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 zero parameters, so the baseline is 4. The description adds no parameter details, but none are needed. Schema coverage is 100% by default with no properties.
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 specific action ('Clears all stored values from the session cache') and the resource affected (session cache). This distinguishes it from sibling tools like get_context, list_context, and capture_context, which deal with reading or capturing 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?
Explicitly says 'Use at the start of a new audit cycle to avoid stale data contamination', giving a clear when-to-use scenario. It does not mention when-not-to-use or alternatives, but the context is sufficient for most agents.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Async resilient HTTP client with anti-blocking (WAF) protection and rate limiting. Supports multiple auth types: bearer, basic, api_key_header, api_key_query, cookie. When stealth mode is enabled, uses random delay between STEALTH_MIN and STEALTH_MAX to evade WAF detection patterns.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | ||
| method | Yes | ||
| stealth | No | ||
| auth_type | No | bearer | |
| body_json | No | ||
| auth_token | No | ||
| auth_key_name | No | ||
| delay_seconds | No | ||
| auth_credentials | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description discloses key behaviors like async execution, stealth mode with random delays, and rate limiting. However, it omits details on side effects, error behavior, credential handling, and uses undefined STEALTH_MIN/MAX constants, leaving some ambiguity.
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 compact and front-loaded, with each sentence conveying relevant capabilities. It avoids unnecessary filler, though the undefined STEALTH_MIN/MAX constants slightly detract from clarity.
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 tool with 9 parameters and no annotations, the description only provides high-level capabilities. It does not explain parameter usage, expected return values, potential failure modes, or when to use the tool within a security workflow, making it incomplete for complex interactions.
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%, and the description only adds meaningful context for auth_type (listing supported types) and stealth (explaining the delay). Other parameters like body_json, auth_credentials, delay_seconds, and auth_key_name are not mapped to the described auth workflows, creating confusion.
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 it is an async HTTP client for executing security requests, with specific capabilities like WAF protection, rate limiting, and multiple auth types. This distinguishes it from sibling tools as the only HTTP client tool in the 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 implies use for making HTTP requests during security testing, but it does not explicitly state when to choose this tool over alternatives like analyze_access_control, nor does it mention scenarios where the other tools should be used. There is no explicit when-not guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Extracts a specific value from a JSON response using dot-notation path. Essential for chained attacks where the LLM needs to grab a dynamically created resource ID from a POST response (e.g. 'data.id' → 42).
| Name | Required | Description | Default |
|---|---|---|---|
| json_path | Yes | ||
| response_json | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of behavioral disclosure. It explains the dot-notation mechanism and gives an example, but does not describe error handling, missing keys, type preservation, or any side effects. It is adequate but not rich.
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 sentences, front-loaded with the action and then a usage scenario. Every sentence earns its place; no waste.
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 tool is simple (2 string params, has output schema). The description covers purpose, usage context, and a param hint, which is sufficient for this complexity. It doesn't explain return value format, but the presence of an output schema reduces that need.
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 0%, so the description must compensate. It clarifies json_path via 'dot-notation path' and example, and implies response_json is a JSON response string. However, it lacks explicit constraints or format details for either parameter, so it only partially compensates.
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 extracts a specific value from a JSON response using dot-notation path, which is a specific verb+resource. It also provides a concrete example ('data.id' → 42) and distinguishes it from siblings like parse_api_spec by focusing on runtime value extraction from responses.
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 gives a clear use case: essential for chained attacks to grab dynamically created resource IDs from POST responses. It does not explicitly mention alternatives or when-not-to-use, but the context is clear enough to guide an agent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Retrieves a previously stored value from the session cache. Returns not_found if the key does not exist. Use to inject dynamic IDs into attack URLs.
| Name | Required | Description | Default |
|---|---|---|---|
| key | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries the full burden. It discloses the `not_found` return behavior for missing keys, which is the key behavioral trait for a getter. It does not describe other traits (e.g., permissions, expiration), but for this simple read operation, it is sufficient.
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?
Three short sentences, each adding essential information: what it does, error behavior, and a use case. No redundant or filler content.
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 simple nature of the tool, the presence of an output schema (which handles return value details), and the clear explanation of the tool's role among siblings, the description is complete enough. It explains the retrieval mechanism, error behavior, and a practical use case.
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 schema only lists `key` as a required string with no description. The description clarifies that the key is used to look up a previously stored value and that a missing key yields `not_found`, adding meaningful context 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 uses the specific verb 'Retrieves' and identifies the resource as 'a previously stored value from the session cache', clearly distinguishing it from sibling tools like `capture_context` (stores) and `list_context` (lists all). It also states the key-based lookup behavior.
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?
It provides an explicit use case ('Use to inject dynamic IDs into attack URLs') but does not mention any exclusions or alternatives, so it earns a 4 rather than a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Returns all key-value pairs stored in the session cache. Useful for the LLM to see what dynamic IDs are available for chained attack flows.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It clearly implies a read-only operation via 'Returns' and specifies the data source (session cache). It does not mention edge cases, ordering, or potential side effects, but for a simple list operation, the transparency is adequate.
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 two sentences, front-loaded with the action ('Returns all key-value pairs'). Every word contributes meaningful context, making it highly efficient 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?
The tool is simple with no parameters and an existing output schema. The description covers what it does, the data source, and a specific use case, making it complete for an agent to understand when to invoke it.
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 zero parameters, so there are no parameter semantics to clarify. The baseline of 4 applies because the schema already shows an empty parameters object, and the description does not need to explain anything further.
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 returns all key-value pairs in the session cache, using a specific verb ('Returns') and resource. It distinguishes itself from sibling tools like get_context or capture_context by emphasizing 'all' pairs.
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 a clear context for when the tool is useful (seeing dynamic IDs for chained attack flows), but does not explicitly name alternatives or when-not-to-use cases. The guidance is implicit rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Reads a local OpenAPI/Swagger file (JSON or YAML), auto-detects format, and selectively extracts routes and methods. Strips verbose descriptions to save up to 70% of LLM tokens.
| Name | Required | Description | Default |
|---|---|---|---|
| spec_path | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the disclosure burden. It reveals several non-obvious behaviors: auto-detects format, selectively extracts routes/methods, and strips verbose descriptions to save tokens. 'Reads' implies non-destructive, though it doesn't explicitly state that the source file is not modified.
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 two tight sentences. The first sentence states the action and resource; the second adds the token-saving benefit. Every word earns its place, and there is no redundant or vague filler.
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 only one simple parameter and an output schema exists, the description is largely sufficient. It explains the core behavior, formats, and purpose. However, 'selectively extracts' is somewhat vague regarding selection criteria, and failure/error handling is not mentioned, though that is not strictly required.
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 only one parameter (spec_path) with zero schema description coverage. The description hints that spec_path is a local file path ('Reads a local... file') but never explicitly says the parameter is the path or discusses accepted path formats or edge cases. It adds some meaning but not enough to fully compensate for the schema 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 uses a specific verb ('Reads') and identifies the exact resource ('local OpenAPI/Swagger file'), the input formats ('JSON or YAML'), and the core output ('routes and methods'). It also differentiates from siblings by focusing on parsing/extracting from an API spec rather than other 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 clearly implies when to use this tool: when you need to read and extract routes/methods from a local OpenAPI or Swagger file. It provides context about format auto-detection and token savings, but it does not explicitly name alternatives or state when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
| Name | Required | Description | Default |
|---|---|---|---|
| title | Yes | ||
| severity | Yes | ||
| description | Yes | ||
| remediation | No | ||
| affected_url | Yes | ||
| evidence_request | No | ||
| evidence_response | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no 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. Dates show when Glama detected each change.
v0.3.1analyze_access_controlcapture_contextclear_contextexecute_security_requestexport_report_jsonextract_json_valuegenerate_reportget_contextlist_contextparse_api_specsave_security_findingMost tools have clear, distinct purposes (e.g., parse_api_spec vs execute_security_request), but generate_report, export_report_json, and save_security_finding lack descriptions, making their boundaries unclear. Additionally, analyze_access_control and execute_security_request both perform HTTP requests, though their intent differs.
All tool names follow a consistent verb_noun snake_case pattern (extract_json_value, save_security_finding, analyze_access_control, etc.). The naming is predictable and uniform across the set.
11 tools is a well-scoped size for an API pentest server. Each tool covers a distinct aspect of the workflow (spec parsing, request execution, access control analysis, context caching, reporting) without excessive overlap or unnecessary additions.
The tool set covers a complete pentest lifecycle: parse spec, execute requests, analyze access control, manage dynamic values, save findings, and generate/export reports. Minor gaps exist, such as no explicit tool for fuzzing or editing requests, but these can be worked around with execute_security_request and context tools.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Security gateway for AI agents: policy, approval, and audited execution, no secrets shared.
Credential broker for AI agents: scoped, revocable API access with policy enforcement and audit.
Pay-per-call cybersecurity for AI agents: vuln scans, threat intel, compliance, code security.
Query your team's drift, vulnerability, and upgrade data from any AI assistant. OAuth 2.1, 51 tools.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/josenieto/mcp-api-pentest'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
