mcp-api-tools is an HTTP/API testing MCP server that provides AI agents with tools to make requests, check endpoint health, decode tokens, parse URLs, and analyze security headers.
Make HTTP Requests (http_request): Send any HTTP method (GET, POST, PUT, DELETE, PATCH, HEAD, OPTIONS) with full control over headers, request body, authentication (Basic or Bearer), timeout, and redirect behavior — returns status code, response headers, body, and timing info.
Check API Health (api_health): Monitor up to 20 API endpoints in parallel, reporting HTTP status, response time, SSL certificate validity/expiry, and optional response body validation, with a summary of healthy/unhealthy/errored endpoints.
Decode JWTs (jwt_decode): Decode a JWT token (without cryptographic verification) to inspect its header, payload, issued-at time, expiry time, and whether it is currently expired.
Parse or Build URLs (url_parse): Break a URL into its components (protocol, host, port, path, query parameters, hash) or construct a URL from individual parts.
Analyze HTTP Security Headers (header_analyzer): Evaluate response headers (from a live URL or a provided headers object) for security posture (HSTS, CSP, X-Frame-Options, X-Content-Type-Options, Referrer-Policy, Permissions-Policy), caching directives, CORS configuration, and cookie attributes — with an overall security letter grade.
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-tools Check the health of https://api.github.com and show response times."
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.
HTTP/API testing tools for AI agents, built on the Model Context Protocol.
http_requestMake any HTTP request (GET, POST, PUT, DELETE, PATCH, HEAD, OPTIONS) with full control over headers, body, authentication, and timeouts. Returns status code, response headers, body, and timing information.
api_healthCheck the health of multiple API endpoints in parallel. Returns HTTP status, response time, SSL certificate validity and expiry, and optional response body validation. Includes a summary with counts of healthy, unhealthy, and errored endpoints.
jwt_decodeDecode a JWT token without cryptographic verification. Returns the decoded header and payload, issued-at time, expiry time, and whether the token is currently expired.
url_parseParse a URL into its component parts (protocol, host, port, path, query parameters, hash) or build a URL from individual parts.
header_analyzerAnalyze HTTP response headers for security posture (HSTS, CSP, X-Frame-Options, X-Content-Type-Options, Referrer-Policy, Permissions-Policy), caching directives, CORS configuration, and cookie attributes. Provides a letter grade for security. Can fetch headers from a live URL or analyze a provided headers object.
Related MCP server: Kiprio MCP
npm install
npm run buildAdd to your claude_desktop_config.json:
{
"mcpServers": {
"api-tools": {
"command": "node",
"args": ["D:/products/mcp-servers/mcp-api-tools/dist/index.js"]
}
}
}claude mcp add api-tools node D:/products/mcp-servers/mcp-api-tools/dist/index.jsMake a POST request:
Use http_request to POST to https://httpbin.org/post with JSON body {"key": "value"}Check API health:
Use api_health to check these endpoints: https://api.github.com, https://httpbin.org/getDecode a JWT:
Use jwt_decode to decode this token: eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9...Parse a URL:
Use url_parse to break down https://example.com:8080/api/v1?key=value&debug=true#sectionAnalyze security headers:
Use header_analyzer to check security headers for https://github.comMIT
Check the health of multiple API endpoints. Returns status, response time, SSL certificate validity, and optional response body validation for each endpoint.
| Name | Required | Description | Default |
|---|---|---|---|
| endpoints | Yes | Array of endpoints to check (max 20) |
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 what the tool returns (status, response time, SSL validity, optional body validation), which is helpful, but it lacks details on rate limits, authentication needs, error handling, or performance implications. For a tool with no annotations, 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 concise and front-loaded, stating the core purpose in the first sentence and detailing the return values in the second. Both sentences earn their place by providing essential information without redundancy. However, it could be slightly more structured by explicitly listing key features, but it's still efficient.
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 (checking multiple endpoints with validation) and no output schema, the description is somewhat complete but has gaps. It covers the purpose and return values but lacks details on behavioral aspects like error handling or performance. Without annotations or an output schema, it should provide more context to be fully helpful.
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 100%, so the schema fully documents the 'endpoints' parameter and its nested properties. The description adds no additional parameter semantics beyond what's in the schema, such as explaining the 'max 20' limit or the purpose of validation checks. With high schema coverage, the baseline score of 3 is appropriate.
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: 'Check the health of multiple API endpoints.' It specifies the verb ('check') and resource ('API endpoints'), making it easy to understand. However, it doesn't explicitly differentiate from sibling tools like 'http_request' or 'header_analyzer', which might also involve API interactions, so it doesn't reach 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. It doesn't mention sibling tools or contexts where this health-check tool is preferred over others, such as 'http_request' for general requests or 'header_analyzer' for header-specific checks. This lack of comparative context leaves the agent without clear usage direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Analyze HTTP response headers for security (HSTS, CSP, X-Frame-Options, etc.), caching directives, CORS configuration, cookies, and server information. Provides a security grade.
| Name | Required | Description | Default |
|---|---|---|---|
| headers | No | HTTP response headers as key-value pairs to analyze | |
| url | No | Alternatively, provide a URL to fetch and analyze its response headers |
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 the tool analyzes headers and provides a security grade, but does not specify if it makes network calls (e.g., when using the 'url' parameter), what the output format is, or any limitations (e.g., rate limits, error handling). This leaves key behavioral traits unclear for an agent.
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 functionality (analyzing headers) and lists key aspects (security, caching, etc.). It avoids unnecessary details, though it could be slightly more structured (e.g., separating input and output aspects).
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 no annotations and no output schema, the description is incomplete for a tool with two parameters and behavioral complexity (e.g., potential network calls). It lacks details on output (what the 'security grade' entails), error cases, or dependencies, making it insufficient for an agent to fully understand tool behavior without trial.
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 100%, so the schema already documents both parameters ('headers' as key-value pairs and 'url' as an alternative). The description adds no additional parameter semantics beyond what the schema provides, such as examples or constraints, but does not contradict it. Baseline 3 is appropriate given high 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 clearly states the tool's purpose with specific verbs ('analyze', 'provides') and resources ('HTTP response headers'), covering security, caching, CORS, cookies, and server information. It distinguishes from siblings like 'http_request' (which makes requests) by focusing on header analysis rather than general HTTP 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 implies usage for analyzing headers for security and other aspects, but does not explicitly state when to use this tool versus alternatives like 'http_request' (which might fetch headers) or 'api_health' (which could check health status). No exclusions or prerequisites are mentioned, leaving usage context somewhat open-ended.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Make an HTTP request with full control over method, headers, body, authentication, and timeouts. Returns status, headers, body, and timing information.
| Name | Required | Description | Default |
|---|---|---|---|
| method | Yes | HTTP method: GET, POST, PUT, DELETE, PATCH, HEAD, OPTIONS | |
| url | Yes | The full URL to send the request to | |
| headers | No | Key-value pairs of HTTP headers to include | |
| body | No | Request body (for POST, PUT, PATCH) | |
| timeout | No | Request timeout in milliseconds (default: 30000) | |
| follow_redirects | No | Whether to follow redirects (default: true) | |
| auth | No | Authentication configuration |
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 control over authentication and timeouts, which hints at security and performance aspects, but lacks details on error handling, rate limits, or side effects. It adequately describes the return values but could be more comprehensive for a tool with such broad capabilities.
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 front-loaded and concise, consisting of two efficient sentences that cover the tool's purpose and return values without any wasted words. Every sentence contributes directly to understanding the tool's functionality.
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 (7 parameters, no annotations, no output schema), the description is somewhat complete but lacks depth. It covers the basics of what the tool does and returns, but for a general-purpose HTTP request tool, more details on error scenarios, security implications, or example use cases would enhance 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?
The schema description coverage is 100%, so the schema already documents all parameters thoroughly. The description adds minimal value by summarizing the parameters ('method, headers, body, authentication, and timeouts') but does not provide additional semantics beyond what the schema offers, aligning with the baseline score for high 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 clearly states the tool's purpose with specific verbs ('Make an HTTP request') and resources ('full control over method, headers, body, authentication, and timeouts'), and distinguishes it from siblings by emphasizing its general-purpose nature versus specialized tools like api_health or jwt_decode.
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 api_health or header_analyzer, nor does it mention any prerequisites or exclusions. It merely states what the tool does without contextual usage advice.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Decode a JWT token without verification. Returns header, payload, expiry, issued-at time, and whether the token is expired.
| Name | Required | Description | Default |
|---|---|---|---|
| token | Yes | The JWT token string to decode |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses key behavioral traits: the tool performs decoding (not verification), returns specific data (header, payload, expiry, issued-at time, expiration status), and handles JWT tokens. However, it lacks details on error handling, input format constraints, or performance characteristics, leaving some 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 front-loads the core purpose and lists return values clearly. Every word earns its place, with no redundancy or unnecessary elaboration, 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 low complexity (one parameter, no output schema, no annotations), the description is nearly complete. It covers purpose, behavior, and outputs adequately. A minor deduction is due to the lack of output schema, which means the description must fully explain return values—it does this well but could benefit from more detail on format or structure.
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 100% description coverage, with the 'token' parameter well-documented in the schema itself. The description adds no additional parameter semantics beyond what the schema provides, so it meets the baseline of 3 for high schema coverage without compensating 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 specific action ('decode a JWT token without verification') and distinguishes it from verification tools. It explicitly mentions what the tool does not do ('without verification'), which helps differentiate it from potential sibling tools that might verify tokens.
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 clear context for when to use this tool ('decode a JWT token without verification'), implying it's for inspection rather than validation. However, it doesn't explicitly mention when not to use it or name specific alternatives among the sibling tools, which prevents a perfect score.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Parse a URL into its component parts: protocol, host, port, path, query parameters, hash, and more. Can also build a URL from parts.
| Name | Required | Description | Default |
|---|---|---|---|
| url | No | URL to parse (use this OR build_params, not both) | |
| build_params | No | Build a URL from parts instead of parsing |
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 the dual functionality but doesn't specify error handling (e.g., for invalid URLs), performance characteristics, or output format. For a tool with no annotation coverage, this leaves significant behavioral gaps, though it at least clarifies the core operations.
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 primary function (parsing) and adds the secondary function (building) without redundancy. Every word earns its place, making it highly concise and well-structured for quick comprehension.
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 (dual functionality, nested parameters) and lack of output schema, the description is minimally complete. It covers the core operations but doesn't address error cases, output format, or detailed usage scenarios. With no annotations and no output schema, more contextual information would be helpful for an agent to use it effectively.
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 100%, so the schema fully documents both parameters (url and build_params). The description adds value by listing specific components (e.g., protocol, host, port) that align with build_params properties, but doesn't provide additional semantic context beyond what's in the schema. This meets the baseline for high 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 clearly states the tool's dual functionality: parsing URLs into components and building URLs from parts. It specifies the exact components extracted (protocol, host, port, path, query parameters, hash) and distinguishes itself from sibling tools which perform different operations like API health checks, header analysis, HTTP requests, and JWT decoding.
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 usage through the phrase 'use this OR build_params, not both' (which appears in the schema, not the description), but the description itself lacks explicit guidance on when to choose parsing vs. building. It doesn't mention alternatives or prerequisites, leaving usage context somewhat implied rather than clearly stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Each tool has a clearly distinct purpose with no overlap: health checks, header analysis, HTTP requests, JWT decoding, and URL parsing. The descriptions specify unique domains (API monitoring, security analysis, HTTP client, token inspection, URL manipulation), making misselection unlikely.
All tool names follow a consistent snake_case pattern with clear, descriptive verb_noun combinations (e.g., api_health, header_analyzer). The naming is uniform and predictable across all five tools, enhancing readability and agent usability.
With 5 tools, the count is well-scoped for an API utilities server, covering essential operations without bloat. Each tool earns its place by addressing a distinct aspect of API testing and analysis, making the set manageable and focused.
The tool surface is nearly complete for API testing and analysis, covering health checks, security headers, HTTP requests, JWT handling, and URL parsing. A minor gap exists in lacking tools for more advanced scenarios like API mocking or load testing, but core workflows are well-supported.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
AI-callable tools for API mocking, testing, monitoring, security, and automation.
Exact hashing, base64/hex/URL encoding, JWT decoding and UUIDs for AI agents. No auth required.
URL intelligence for AI agents and developers. 16 tools, 25 signal weights, 20 free checks.
Utility tools for AI agents: hashing, text stats, validation, DNS, currency, GEO audits.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/rog0x/mcp-api-tools'
If you have feedback or need assistance with the MCP directory API, please join our Discord server