mcp-api-tester Tools & Interfaces
LocalAbout mcp-api-tester Tools & Interfaces
mcp-api-tester Tools & Interfaces describes MCP tools for LLM-assisted API testing. It is aimed at developers who want an LLM to inspect API documentation, send HTTP requests, and assess responses.
Key features
- 01List endpoints from API documentation
- 02Retrieve endpoint parameters and schemas
- 03Send HTTP requests and inspect results
- 04Suggested schema validation and test logging
Use cases
- 01Select endpoints for automated test runs
- 02Check responses against documented schemas
- 03Record outcomes and review endpoint history
MCP support
The document describes MCP tools for reading OpenAPI documentation, listing and detailing endpoints, and making HTTP calls. It also includes a sample JSON-RPC tools/call request.
Configuration
Local server config is the same for every client. Copy it into your client’s MCP config file.
We haven’t collected a package or remote endpoint for this server. Follow the instructions in the project README.
Tools
Local servers expose tools only once running on your machine, and the maintainer has not provided a tool list.
Details
From the project READMEmcp-api-tester Tools & Interfaces
This document summarizes potential tools or interfaces that enable an LLM (Large Language Model) to perform automated API testing. By leveraging these tools, the LLM can read API documentation, select and test specific endpoints using net/http, and help developers quickly identify potential issues.
Core Tools (Minimal Viable Tools)
The following three tools are the most basic and essential interfaces, allowing the LLM to conduct minimum viable automated testing:
-
listAllAPIFromDocument
- Purpose: Lists all available APIs (name, URL, HTTP method, etc.) from the documentation.
- Example: A sample return value might look like:
[ { "name": "getUser", "method": "GET", "url": "/users/{id}" }, { "name": "createUser", "method": "POST", "url": "/users" } ... ] - When the LLM Uses It: To browse available APIs and choose which to test.
-
getSingleAPIDetail
- Purpose: Retrieves detailed documentation of a specific API by name or path, such as:
- Request parameters (query, path, body, etc.)
- Response structure (schema)
- Possible status codes and error definitions
- Example: A sample return value might look like:
{ "name": "getUser", "method": "GET", "url": "/users/{id}", "parameters": [ { "in": "path", "name": "id", "type": "string", "required": true } ], "responses": { "200": { "description": "Returns user data on success", "schema": { ... } }, "404": { "description": "User not found" } } } - When the LLM Uses It: To generate test parameters and expected responses for a specific endpoint.
- Purpose: Retrieves detailed documentation of a specific API by name or path, such as:
-
callNetHTTP
- Purpose: Allows the LLM to send real HTTP requests and receive results (status code, headers, body).
- Example:
{ "request": { "method": "POST", "url": "/users", "headers": { "Content-Type": "application/json" }, "body": { "name": "NewUser", "age": 30 } }, "response": { "status": 201, "headers": { ... }, "body": { "id": "123", "name": "NewUser", "age": 30 } } } - When the LLM Uses It: To execute test calls and compare actual results against expected outcomes.
Advanced Suggested Tools (Enhanced Tools)
These tools are not mandatory, but they can significantly improve automated testing, reporting, environment setup, and more.
1. Response Validation / Parsing Tools
-
Schema Validation
validateResponseWithSchema(responseBody, schemaInfo) -> (isValid, errorList)- Compares the returned JSON body against the documented schema to check for field consistency, data types, and any required fields.
-
JSON Parsing
parseJSON(responseBody) -> (parsedObject)- Enables the LLM to conveniently read and inspect specific fields in the response (e.g., confirm that certain fields are not empty).
2. Context / Logging Tools for Test Execution
-
Test Result Logging / Storage
storeTestResult(testCase, response, passOrFail, errorMessage)- Lets the LLM record execution details, errors, and outcomes for each test case, making it easier to compile reports.
-
Historical Test Results
getTestHistory(apiName or endpoint) -> (historyData)- Allows the LLM (or other systems) to query past test results for the same endpoint and understand regressions or changes over time.
3. Environment Setup / Management Tools
-
Authentication / Credential Setup
getAuthToken(username, password) -> token- Some APIs require a token or cookie for authentication. The LLM may need to call this tool first to obtain proper credentials.
-
Reset / Initialize Test Data
resetTestData()orseedTestData()- Ensures the database or system state is in a known default condition before testing begins.
4. Fuzz / Edge Case Testing Tools
- generateFuzzyInput(fieldType, constraints)
- Returns extreme or unusual input (e.g., negative values, extremely large values, random characters, special symbols) for stress-testing and security checks.
Recommended Development Flow
-
Integrate the Minimal Viable Tools
- Implement
listAllAPIFromDocument,getSingleAPIDetail, andcallNetHTTPin your system so the LLM can:- Obtain a list of available endpoints
- Fetch detailed specs for a given API
- Make real HTTP requests
- Implement
-
Connect the LLM
- Enable the LLM to use the above three tools. It can list potential endpoints, retrieve details for each, generate test scenarios, and finally run them via
callNetHTTP.
- Enable the LLM to use the above three tools. It can list potential endpoints, retrieve details for each, generate test scenarios, and finally run them via
-
Add Validation Tools (Response / Schema)
- Provide utilities that let the LLM verify whether returned data matches the documented schema and expectations.
-
Expand on Test Logging & Environment Management
- Offer interfaces for storing test results, querying historical tests, resetting the environment, and retrieving auth tokens.
- The LLM can call these tools to maintain a consistent state and documentation of test processes.
-
Fuzz / Edge Case Testing
- Integrate a tool to generate malicious or extreme values, or let the LLM generate them automatically to conduct in-depth stress or security testing.
Important Notes
-
Security & Permissions
- When the LLM makes API calls, ensure these tests run in a safe environment (development or sandbox) and do not compromise sensitive data.
-
Accuracy of LLM-Generated Content
- The LLM may produce invalid or incorrect parameters. Additional validation or error handling may be needed in your interfaces.
-
Cannot Completely Replace Traditional Testing
- While the LLM can quickly produce boundary and abnormal test cases, traditional unit tests remain essential for thorough coverage.
Test
ReadOpenAPIDocument
curl -X POST --data '{
"jsonrpc": "2.0",
"id": 1,
"method": "tools/call",
"params": {
"name": "ReadOpenAPIDocument",
"arguments": {
"openAPIPath": "/absolute/path/to/your/openAPI/file"
}
}
}' http://localhost:8000/message?sessionId=9fa4fc8c-1799-4955-a0bb-4881258f13f9
ListAllAPIFromDocument
curl -X POST --data '{
"jsonrpc": "2.0",
"id": 1,
"method": "tools/call",
"params": {
"name": "ListAllAPIFromDocument"
}
}' http://localhost:8000/message?sessionId=9fa4fc8c-1799-4955-a0bb-4881258f13f9
Comments
New to MCP?
From what the protocol is to installing your first server, these answers cover most first questions.
An open protocol that defines how AI applications connect to external tools and data in a uniform way. Clients talk to the model; MCP servers provide tools, resources and prompt templates. They exchange standard messages, so one server can be reused by many clients.