mcpField
M
mcp-api-tester Tools & Interfaces

mcp-api-tester Tools & Interfaces

Local
github.com/TinyMurkyDeveloper Tools0Updated 73w ago

About 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

  1. 01List endpoints from API documentation
  2. 02Retrieve endpoint parameters and schemas
  3. 03Send HTTP requests and inspect results
  4. 04Suggested schema validation and test logging

Use cases

  1. 01Select endpoints for automated test runs
  2. 02Check responses against documented schemas
  3. 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.

No install method listed yet

We haven’t collected a package or remote endpoint for this server. Follow the instructions in the project README.

Repository

Tools

No tool list yet

Local servers expose tools only once running on your machine, and the maintainer has not provided a tool list.

Details

From the project README

mcp-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:

  1. 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.
  2. 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.
  3. 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
  1. 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.
  2. 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
  1. 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.
  2. 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
  1. 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.
  2. Reset / Initialize Test Data

    • resetTestData() or seedTestData()
    • 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

  1. Integrate the Minimal Viable Tools

    1. Implement listAllAPIFromDocument, getSingleAPIDetail, and callNetHTTP in your system so the LLM can:
      • Obtain a list of available endpoints
      • Fetch detailed specs for a given API
      • Make real HTTP requests
  2. 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.
  3. Add Validation Tools (Response / Schema)

    • Provide utilities that let the LLM verify whether returned data matches the documented schema and expectations.
  4. 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.
  5. 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

Markdown supported

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.