drill-mcp

Official

by apache

Overview Schema Related Servers Score Discussions

Python

Remote

Server Quality Checklist

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

Latest release: v0.1.0
Disambiguation5/5
Each tool targets a distinct resource and action: query execution, schema/table listing, table description, storage plugin configs, cluster status, and query profile management. There is no overlap in purpose, so an agent can reliably select the correct tool.
Naming Consistency4/5
Most tools follow a consistent verb_noun pattern using snake_case (run_query, list_schemas, list_tables, describe_table, list_storage_plugins, list_profiles, get_profile, cancel_query). The only deviation is 'cluster_status', which lacks an explicit verb but remains clear and readable.
Tool Count5/5
With 9 tools, the set is well-scoped for a Drill MCP server. It covers metadata exploration, query execution, cluster health, and query management without unnecessary bloat, fitting comfortably within the ideal 3-15 range.
Completeness4/5
The server covers the core lifecycle of query interaction: running a query, inspecting profiles, and canceling. It also provides comprehensive metadata browsing via schemas, tables, and columns. Minor gaps exist such as lack of write operations or cross-schema table listing, but these are not critical for typical read-oriented Drill usage.
Average 3.6/5 across 9 of 9 tools scored. Lowest: 2.9/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 59 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 passing
This repository is licensed under Apache 2.0.
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?
With no annotations, the description carries the full burden of behavioral disclosure. It merely says 'run' and 'return its rows' without stating whether write statements are permitted, what permissions are required, or what occurs for non-SELECT statements. This is a significant gap for a tool that executes arbitrary SQL.
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, front-loaded sentence with no redundant words. It efficiently communicates the core action and outcome.
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?
Despite having an output schema, the tool description is underspecified for a tool that can execute arbitrary SQL. It lacks safety warnings, usage context, and parameter nuances. An agent would not know whether this tool might mutate data or how to handle large result sets without additional information.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
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. The phrase 'single SQL statement' implicitly aligns with the 'sql' parameter, but there is no explanation of 'max_rows' or the expected format of the SQL. The description adds essentially no parameter-level meaning beyond what the schema already shows.
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 uses the specific verb 'run' with the resource 'a single SQL statement against Drill' and states it returns rows. This clearly distinguishes it from sibling tools like list_tables and describe_table, which are metadata-oriented.
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?
No guidance is provided on when to use this tool versus alternatives. It does not mention that this is the tool for arbitrary ad-hoc SQL queries, nor does it warn when it should not be used (e.g., for read-only data exploration vs. potential writes).
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 the full burden of behavioral disclosure. It only states the operation is 'List', implying read-only behavior, but does not mention permissions, whether views are included, output format, or any side effects. This is minimal 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 a single, simple sentence with no redundant information. It is appropriately front-loaded and achieves maximum conciseness.
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?
Despite having an output schema, the description lacks essential contextual information: it does not differentiate from list_schemas, specify if the schema must be pre-existing, or mention whether the result includes only user-defined tables. Given the sparse sibling context, this is insufficient for reliable tool invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 0%, and the description does not compensate. While the text mentions 'one schema', it does not explain the expected format, whether it is a schema name or identifier, or any constraints. This adds barely more meaning than the schema property title 'Schema'.
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 tool's purpose: 'List the tables in one schema.' The verb 'List' identifies a read operation on a specific resource ('tables'), and 'in one schema' clarifies the scope. This differentiates it from sibling tools like list_schemas (which lists schemas) and describe_table (which describes a single table).
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 offers no guidance on when to use this tool versus alternatives such as list_schemas, describe_table, or run_query. It does not mention prerequisites (e.g., the schema must exist) or any exclusions. The only implied usage is that it returns tables for a given schema, which is not enough for informed selection.
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 the full burden. It only states the action without explaining side effects, whether cancellation is immediate or asynchronous, what happens if the query ID is invalid, or if there are any prerequisites. This is a significant gap for a mutation tool.
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, front-loaded sentence with no redundant information. Every word earns its place, making it highly concise and scannable.
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 simple one-parameter tool, the description is minimally adequate, but it lacks caveats like idempotency, error behavior, or asynchronous completion. While an output schema exists, the description still leaves important operational details to guesswork.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides a bare 'query_id' string with no description (0% coverage). The description only repeats 'by its query id' without clarifying formats, where to find it, or any constraints. This does not compensate for the lack of schema documentation.
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 action ('Cancel') and the resource ('a running query'), with the identifier method ('by its query id'). This distinctively separates it from siblings like run_query, making the purpose unambiguous.
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?
Usage context is implied by the description and name; the agent can infer it should be used when a query is running and needs to be stopped. However, there is no explicit guidance on when to use it versus alternatives or when not to use it, such as if the query has already completed.
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, but the read-only nature is implicit from the 'describe' action. The description does not disclose potential errors, permission requirements, or side effects, though the output schema covers return values. It adds minimal behavioral context beyond the core function.
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, concise sentence that front-loads the verb and resource. No unnecessary words or redundancy.
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 simplicity and the presence of an output schema, the description provides the core purpose but lacks guidance on parameter usage and any edge cases. It is a minimum-viable description that is not misleading but could be more thorough.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not explain the parameters schema and table. While the parameter names are self-explanatory, the description adds no additional meaning beyond what the schema already provides (e.g., format, constraints, or which parameter is which).
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 explicitly states the tool's action (List), resource (table's columns), and specific output details (types and nullability). This clearly distinguishes it from sibling tools like list_tables and list_schemas.
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 for inspecting a specific table's schema but provides no explicit comparison to alternatives like run_query or any conditions. It is adequate but lacks direct guidance on when to choose this over other tools.
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?
There are no annotations provided, so the description carries the burden. It discloses that results are sorted newest first and are limited to recent and running profiles. However, it does not disclose whether this requires specific permissions, whether it's read-only (though list implies), or any pagination behavior. Minimal but not misleading.
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 front-loaded sentence: 'List recent and running query profiles, newest first.' It conveys purpose, scope, and ordering with no wasted words.
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?
The tool is simple with one optional parameter and an output schema, but the description is minimal. It covers purpose and ordering, but lacks parameter semantics and usage guidance compared to alternatives. Given the complexity, the description has some gaps but is minimally viable.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has one parameter 'limit' with a default of 20, and schema description coverage is 0%. The description does not mention the limit parameter at all, forcing the agent to infer its semantics from the parameter name. This is a gap, though the parameter name is simple.
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 uses the specific verb 'List' and clearly identifies the resource as 'query profiles', with qualifiers 'recent and running' and ordering 'newest first'. This distinguishes it from siblings like get_profile (specific profile) and cancel_query.
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 states what the tool does but provides no explicit guidance on when to use it versus alternatives like get_profile. Usage is implied by the name and description, but no exclusions or alternatives are mentioned.
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 the full burden of behavioral disclosure. It mentions 'report' which implies a read-only operation, but does not elaborate on what 'membership' includes, whether any prerequisites exist, or any potential side effects. The description is too terse to be fully transparent.
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, concise sentence that directly communicates the tool's purpose with no filler or redundant content. It is perfectly sized for the simplicity of the tool.
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 has no parameters and an output schema exists, the description need not explain return values. The description is sufficient for a simple status-checking tool, though it could be slightly more explicit about what constitutes 'cluster status' for full completeness.
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 tool has zero parameters, so there are no parameter semantics to clarify. The description is not required to compensate for missing parameter details, and the baseline for zero parameters is appropriately set to 4.
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 tool reports Drillbit membership and overall cluster status, using a specific action verb and resource. It is easily distinguishable from sibling tools that focus on queries, schemas, and profiles.
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 for checking cluster health and membership but provides no explicit guidance on when to use it versus alternatives. There are no exclusions or mention of alternative tools, so it lacks clear usage 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 behavioral burden. The verb 'Fetch' implies a safe read operation, but it does not disclose potential errors (e.g., if query_id is not found), permissions required, or that it returns no side effects. It is minimally transparent enough for a simple read, but lacks richer context.
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, focused sentence that immediately communicates the essential action and target. No unnecessary words or repetition; every part earns its place.
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 simplicity (one required parameter) and the presence of an output schema, the description is mostly complete. It clearly states what is fetched and for which entity. However, it could be more helpful by noting how it relates to list_profiles (e.g., 'use this for a single profile, not list_profiles'), which would tie it into the broader tool set.
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 only provides the parameter name and type, with no description (0% coverage). The description adds semantic meaning by stating 'for one query id', clarifying that query_id is the identifier of the query whose profile is fetched. This compensates for the schema gap, though it does not specify format or origin of the id.
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 uses a specific verb ('Fetch'), names the resource ('the full profile'), and scopes it to 'one query id', clearly distinguishing it from siblings like list_profiles which lists multiple profiles. The purpose is immediately clear and unambiguous.
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 indicating it operates on a single query id, suggesting it should be used when you need one specific profile rather than a list. However, it does not explicitly compare to siblings like list_profiles or mention when not to use it, so guidance is only implied.
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 partially carries the transparency burden. It discloses a notable behavior—secrets are redacted—which adds value. However, it doesn't mention other important aspects like whether the list is read-only, whether plugin types are filtered, or performance considerations, leaving gaps in 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that is direct and front-loaded. It states the core function first and adds one piece of important context (redaction) without any filler. Every word earns its place.
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 zero-parameter list tool with an output schema, the description captures the essential purpose and the key redaction behavior. It could be enriched with what 'storage plugin configurations' entails or how the list is scoped, but given the low complexity and output schema availability, it is adequately complete.
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 tool has zero parameters, so the description need not explain parameter meanings. The schema coverage is 100% (vacuously), and the description adds the redaction context, which is relevant to interpreting output. Baseline for 0 params is 4, and the description meets that standard.
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 tool's action ('List') and resource ('storage plugin configurations'), making its purpose specific and distinct from sibling list tools like list_tables and list_profiles. It names the resource type unambiguously, eliminating confusion about what it operates on.
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 (use when you need storage plugin configurations) but provides no explicit guidance on when to prefer this tool over alternatives or any exclusions. It doesn't reference sibling tools or clarify boundary conditions, so context is inferred rather than explicit.
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 behavioral burden. It implies a read-only operation ('List') and specifies scope ('on the cluster'), but does not disclose potential limitations, permissions, or system schema inclusion. This is acceptable for a simple list operation.
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, front-loaded sentence with no wasted words. It immediately states the action and scope.
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, the description is concise and sufficiently complete. It clarifies that all schemas on the cluster are listed, which differentiates it from related tools. The presence of an output schema reduces the need to explain return values.
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 no parameters, so schema coverage is trivially 100%. The description adds no parameter-specific information, but none is needed. Baseline for 0 params is 4.
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 uses a specific verb ('List') and clearly identifies the resource ('every schema visible on the cluster'). It distinguishes itself from sibling tools like list_tables and describe_table by explicitly targeting schemas.
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 about what the tool does (lists all schemas), but does not explicitly mention when to use it compared to alternatives. However, the scope is unambiguous and 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.

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:

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

Score Badge

Copy to your README.md:

[![drill-mcp MCP server](https://glama.ai/mcp/servers/apache/drill-mcp/badges/score.svg)](https://glama.ai/mcp/servers/apache/drill-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/apache/drill-mcp'

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