TurboPentest

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v0.1.5
Disambiguation5/5
Each tool has a distinct purpose with clear boundaries: download_report retrieves reports, get_credits checks balances, get_findings provides vulnerability details, get_pentest gives full test details, list_domains shows domain status, list_pentests lists tests, start_pentest launches tests, and verify_attestation verifies authenticity. No overlap or confusion exists between these functions.
Naming Consistency5/5
All tools follow a consistent verb_noun pattern using snake_case: download_report, get_credits, get_findings, get_pentest, list_domains, list_pentests, start_pentest, and verify_attestation. This uniformity makes the toolset predictable and easy to navigate.
Tool Count5/5
With 8 tools, the count is well-scoped for a pentesting server, covering essential operations like launching tests, retrieving results, managing domains, and verifying attestations. Each tool earns its place without redundancy or bloat.
Completeness5/5
The toolset provides complete coverage for the pentesting domain: it supports the full lifecycle from domain verification and test initiation to retrieving findings, reports, and attestation verification. No obvious gaps exist; agents can perform all core workflows seamlessly.
Average 3.7/5 across 8 of 8 tools scored. Lowest: 2.9/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 0 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is failing
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It describes what details are returned but doesn't disclose behavioral traits like whether this is a read-only operation, authentication requirements, rate limits, error conditions, or pagination. For a tool with no annotations, this leaves significant gaps in understanding how it behaves.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the purpose and lists included details. Every word earns its place with no redundancy or fluff, making it easy for an agent to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
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. It lists return details but doesn't explain the structure, format, or potential errors. For a tool that returns complex data (e.g., executive summary, threat model), more context is needed to help the agent use it effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with the parameter 'pentest_id' clearly documented as a UUID in the schema. The description doesn't add any meaning beyond what the schema provides (e.g., it doesn't explain where to get the pentest_id from or format nuances). Baseline 3 is appropriate when the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Get' and resource 'pentest' with specific details included (status, progress, findings summary, etc.). It distinguishes from siblings like 'list_pentests' (which likely lists multiple pentests) and 'get_findings' (which likely focuses only on findings). However, it doesn't explicitly contrast with all siblings, so it's not a perfect 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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_pentests' or 'get_findings'. It doesn't mention prerequisites (e.g., needing a pentest ID) or context for usage. The agent must infer usage from the tool name and parameter alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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 the tool retrieves 'structured vulnerability findings' and includes a severity filter, but doesn't disclose behavioral traits like whether this is a read-only operation, potential rate limits, authentication needs, pagination, or what happens if no findings exist. For a tool with no annotations, this leaves significant gaps in understanding its behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded: the first sentence defines the core purpose and key attributes, and the second sentence provides usage guidance. Both sentences earn their place by adding value. It could be slightly more structured (e.g., bullet points for attributes), but it's efficient with zero waste.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
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 moderately complete for a read operation. It covers the purpose and basic usage but lacks details on behavioral aspects (e.g., response format, error handling) and doesn't fully compensate for the missing output schema. It's adequate but has clear gaps for a tool retrieving structured data.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with clear descriptions for both parameters (pentest_id as UUID, severity as enum filter). The description adds minimal value beyond the schema: it mentions 'severity filter' but doesn't explain parameter interactions or semantics further. Baseline 3 is appropriate since the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
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 structured vulnerability findings for a pentest' with specific attributes listed (severity, CVSS, CWE, etc.). It distinguishes from siblings like 'download_report' or 'get_pentest' by focusing on vulnerability findings rather than reports or pentest metadata. However, it doesn't explicitly contrast with all siblings (e.g., 'list_domains'), keeping it at 4 rather than 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides some usage context: 'Use the severity filter to narrow results' implies this tool is for retrieving findings, possibly with filtering. However, it lacks explicit guidance on when to use this vs. alternatives like 'download_report' (which might include findings) or prerequisites (e.g., requires a pentest_id). The context is implied but not comprehensive.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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 ordering ('newest first') and what data is returned ('status and finding counts'), but doesn't cover important aspects like pagination behavior (only mentions 'limit' parameter), authentication requirements, rate limits, error conditions, or whether this is a read-only operation. For a listing tool with no annotation coverage, this leaves significant gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with zero wasted words. It's front-loaded with the core purpose and includes only essential additional details about ordering and data included. Every element earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a listing tool with 2 parameters (fully documented in schema) and no output schema, the description provides basic but incomplete context. It covers what data is returned and ordering, but lacks information about response format, pagination beyond the 'limit' parameter, error handling, and authentication requirements. Given the complexity level and absence of annotations/output schema, this is minimally adequate but has clear gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
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. The description doesn't add any parameter-specific information beyond what's in the schema (no syntax hints, format details, or usage examples). This meets the baseline of 3 when the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
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 ('all your pentests') with additional details about what information is included ('status and finding counts'). It distinguishes from some siblings like 'get_pentest' (singular) and 'start_pentest' (creation), but doesn't explicitly differentiate from 'list_domains' which is a similar listing operation for a different resource.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage by mentioning ordering ('newest first'), but provides no explicit guidance on when to use this tool versus alternatives like 'get_pentest' (for a specific pentest) or 'get_findings' (for detailed findings). No prerequisites, exclusions, or comparative context with siblings is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
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 indicates this is a read operation ('check') and mentions the purpose of credits for launching pentests, adding useful context. However, it doesn't disclose details like authentication needs, rate limits, or error handling, which are important for a tool that interacts with billing or resource systems.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately sized and front-loaded, consisting of two concise sentences that directly state the tool's function and its relevance to pentests. Every sentence earns its place by adding clear information without redundancy or unnecessary details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity (0 parameters, no output schema, no annotations), the description is complete enough for basic understanding. It explains what the tool does and why it matters, though it could benefit from more behavioral details (e.g., response format or error cases) to fully compensate for the lack of structured data.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0 parameters with 100% coverage, so no parameter documentation is needed. The description adds value by explaining the semantic output ('credit balance and available scan tiers with pricing'), which compensates for the lack of an output schema. This goes beyond the schema, providing meaningful context for what the tool returns.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
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 ('check', 'launch') and resources ('credit balance', 'available scan tiers with pricing', 'pentests'), making it easy to understand what the tool does. However, it doesn't explicitly differentiate from sibling tools like 'list_pentests' or 'get_pentest', which might also relate to pentest operations but focus on different aspects.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage by stating 'Credits are required to launch pentests,' suggesting this tool should be used before starting a pentest to check resource availability. However, it lacks explicit guidance on when to use this tool versus alternatives (e.g., no comparison to sibling tools) or any exclusions, leaving some ambiguity in context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
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 prerequisite condition ('The scan must be complete'), which is valuable context. However, it doesn't describe other behavioral traits like authentication requirements, rate limits, error conditions, or what happens if the scan isn't complete, leaving gaps 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise and front-loaded, consisting of just two sentences that efficiently convey the tool's purpose, parameter usage, and prerequisite condition. Every sentence adds value with no wasted words, making it easy for an AI agent to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
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 output schema, no annotations), the description is somewhat complete but has gaps. It covers the purpose and prerequisite well, but lacks details on behavioral aspects (e.g., error handling, output structure) that would be helpful for an agent, especially without annotations or an output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
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 thoroughly. The description adds some semantic context by explaining the purpose of each format option (e.g., 'markdown for AI-readable content'), but this is largely redundant with the schema's enum descriptions. Baseline 3 is appropriate when the schema does most of the work.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('Download a pentest report') and resource ('pentest report'), distinguishing it from siblings like 'get_pentest' (likely metadata) or 'get_findings' (specific findings). It provides a clear verb+resource combination that is distinct from other tools in the list.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
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 ('The scan must be complete'), which is essential guidance. However, it doesn't explicitly mention when NOT to use it or name alternatives among siblings (e.g., 'get_pentest' for non-report data), so it falls short of the highest score.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses key behavioral traits: it's a launch/mutation operation (implied by 'Launch'), requires verification and credits, and mentions scanning tiers. However, it lacks details on rate limits, response format, or error handling.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences are front-loaded with essential information (action, target, prerequisites), with zero wasted words. Each sentence earns its place by covering critical usage constraints.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with no annotations and no output schema, the description is moderately complete. It covers prerequisites and tier context, but lacks details on what happens after launch (e.g., async process, report generation) or error scenarios, leaving gaps in operational understanding.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
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 all parameters well. The description adds minimal value beyond the schema, only implying target_url must be verified and tier affects credit usage, but no additional syntax or format details.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('Launch an AI-powered penetration test') and target resource ('against a target URL'), distinguishing it from siblings like list_domains or get_pentest by focusing on initiating a scan rather than querying existing data.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides explicit prerequisites (domain must be verified via list_domains, requires available credit) and context (matching the selected tier), but does not specify when to use alternatives like get_findings or list_pentests for post-scan actions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
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 implies a read-only operation ('List') and adds useful context about verification status and prerequisites for pentests, but lacks details on permissions, rate limits, or response format.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences that are front-loaded with the core purpose and follow with essential context. Every sentence earns its place without redundancy or waste.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list tool with no parameters, no output schema, and no annotations, the description is reasonably complete—it explains what it does and why it matters. However, it could benefit from mentioning return format or pagination to be fully comprehensive.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0 parameters and 100% schema coverage, the baseline is 4. The description adds no parameter-specific information, which is acceptable since there are no parameters to document.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('List') and resource ('your verified domains and their verification status'), distinguishing it from siblings like 'list_pentests' or 'get_findings' by focusing on domain verification rather than pentests or findings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides clear context for when to use this tool ('Domains must be verified before you can run pentests against them'), linking it to the pentest workflow. However, it does not explicitly state when not to use it or name alternatives among siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
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 adds valuable context beyond basic functionality: it specifies this is a 'public endpoint — no API key required', which informs authentication needs, and implies read-only verification without destructive effects, though it doesn't detail rate limits or exact response format.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the core purpose, followed by key behavioral details, all in two efficient sentences with zero wasted words. Each sentence earns its place by adding distinct value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity (1 parameter, no output schema, no annotations), the description is largely complete. It covers purpose, usage context, and key behavioral traits like public access. However, without an output schema, it doesn't explain return values (e.g., verification status or error details), leaving a minor gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 100%, so the parameter 'hash' is already documented in the schema. The description adds marginal meaning by linking the hash to verification of pentest authenticity, but doesn't provide additional syntax or format details beyond what the schema states.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('verify'), resource ('blockchain-anchored pentest attestation'), and mechanism ('by its hash'). It distinguishes this from sibling tools like 'download_report' or 'get_pentest' by focusing on verification rather than retrieval or listing.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
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 ('to confirm that a pentest was actually performed and its results are authentic'), but does not explicitly mention when not to use it or name specific alternatives among the sibling tools (e.g., 'get_pentest' for retrieving details).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![turbopentest-mcp MCP server](https://glama.ai/mcp/servers/IntegSec/turbopentest-mcp/badges/card.svg)](https://glama.ai/mcp/servers/IntegSec/turbopentest-mcp)

Score Badge

Copy to your README.md:

[![turbopentest-mcp MCP server](https://glama.ai/mcp/servers/IntegSec/turbopentest-mcp/badges/score.svg)](https://glama.ai/mcp/servers/IntegSec/turbopentest-mcp)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/IntegSec/turbopentest-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server