mcp-db-analyzer

Server Quality Checklist

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

Latest release: v0.2.14
Disambiguation5/5
Each tool addresses a distinct database analysis concern (connections, indexes, slow queries, etc.). Overlaps like analyze_indexes and suggest_missing_indexes are clearly differentiated by their descriptions, ensuring an agent can select the correct tool without confusion.
Naming Consistency5/5
All tools follow a consistent verb_noun pattern in snake_case (e.g., analyze_connections, explain_query). This predictable structure aids agent understanding and navigation.
Tool Count5/5
With 9 tools, the server is well-scoped for its purpose of database analysis. Each tool serves a specific need without redundancy or bloat.
Completeness5/5
The tool set covers a comprehensive range of database analysis tasks: connections, indexes, slow queries, bloat, relationships, vacuum, explain, schema inspection, and index suggestions. There are no obvious gaps for a server focused on analysis and optimization.
Average 3.8/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
- 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 provided, so the description must disclose behavioral traits. It mentions what metrics are checked but does not state whether the tool is read-only, requires specific permissions, or has side effects. For a diagnostic tool, it omits important safety information.
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?
A single sentence that efficiently conveys the tool's purpose and scope. No redundancy, but could benefit from clearer separation of the separate metrics. Still, it is well front-loaded.
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?
With only two simple parameters and no output schema, the description explains what the tool checks but omits details about the return format, supported databases beyond mentioning Postgres and MySQL, and potential errors. Adequate but not fully complete.
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 coverage is 100% (both parameters have descriptions). The description adds no additional meaning beyond the schema's parameter descriptions. Baseline score of 3 is appropriate as the schema already documents parameters adequately.
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 analyzes table bloat by checking specific metrics (dead tuple ratios, InnoDB fragmentation, vacuum history, table sizes). It includes database-specific details but does not explicitly differentiate from siblings like analyze_vacuum, which may have overlapping vacuum history checks.
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 explicit guidance on when to use this tool versus alternatives. The description implies it targets PostgreSQL and MySQL, but does not state prerequisites or scenarios where it is preferred over sibling tools like analyze_vacuum or inspect_schema.
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. It discloses what is checked but omits behavioral traits such as whether the tool modifies data (assumed read-only), required permissions, output format, or side effects. Identifying tables needing manual vacuum hints at output but lacks detail. This is minimal 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?
Two concise sentences with zero wasted words. The first sentence states the core action, the second adds detail on checks and constraints. Information is front-loaded and easily parsed.
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 diagnostic tool with 2 optional parameters and no output schema, the description provides the core purpose and checks but lacks details on output interpretation, prerequisites (e.g., database access), or how the results should guide action. It is adequate but not fully complete given the complexity of vacuum analysis.
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%; both parameters (schema, timeout_ms) have descriptions in the input schema. The description adds no further meaning beyond the schema, so baseline 3 is appropriate.
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: analyzing PostgreSQL VACUUM maintenance status. It specifies the exact checks performed (dead tuple ratios, vacuum staleness, autovacuum configuration, tables needing manual VACUUM) and includes the constraint 'PostgreSQL only,' which clearly distinguishes it from siblings like analyze_connections or analyze_indexes.
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 vacuum status but does not explicitly state when to use this tool versus alternatives. It lacks exclusions or comparison with sibling tools. The constraint 'PostgreSQL only' gives some guidance, but no direct 'when-not-to-use' or alternative tool names are mentioned.
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 bears full burden. It describes the output (unused indexes, missing indexes, unindexed foreign keys) but does not disclose behavioral traits such as whether the tool is read-only, resource-intensive, or requires specific permissions. The verb 'analyze' implies no modification, but this is not explicit.
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 two sentences long and immediately states the core value proposition. Every sentence adds distinct information about what the tool finds (unused indexes, missing indexes, unindexed foreign keys). No redundant or unnecessary text.
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 lack of annotations and output schema, the description provides a clear overview of the tool's outcomes (unused and missing indexes, unindexed foreign keys). It does not explain the return format or any side effects, but the information is sufficient for an agent to understand the tool's primary function.
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?
All three parameters (schema, mode, timeout_ms) have descriptions in the input schema (100% coverage), so the baseline is 3. The tool description does not add any additional meaning or usage tips beyond what the schema already provides.
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: analyzing index usage statistics to find unused indexes, missing indexes, and unindexed foreign keys. It uses specific verbs and resources, and the purpose is distinct from sibling tools like analyze_connections or analyze_slow_queries.
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 (e.g., suggest_missing_indexes). The description does not mention when-not to use it or any prerequisites. Users must infer usage context solely from the tool's name.
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 full burden for behavioral disclosure. It states the tool provides recommendations but does not explicitly confirm it is read-only (no side effects), mention any performance impact, or indicate required permissions. This leaves some behavioral uncertainty.
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 efficiently convey purpose and output. Information is front-loaded with the key action ('Find tables...') followed by the output type. No unnecessary words.
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 no output schema, the description reasonably indicates the tool returns actionable SQL recommendations. However, it does not detail the format (e.g., list of strings, structured objects). Slight improvement could specify output structure, but overall adequate for a simple tool.
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 coverage is 100% with both parameters described ('schema' default public, 'timeout_ms' default 30000 with hint). The tool description adds no additional parameter semantics beyond what the schema already provides, so baseline score of 3 applies.
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: identifying tables with high sequential scans and zero index usage, cross-referenced with unused indexes, and providing CREATE INDEX and DROP INDEX recommendations. This distinguishes it from sibling tools like analyze_indexes which likely focus on existing indexes.
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 context (analyzing missing and unused indexes) but does not explicitly state when to use this tool versus alternatives like analyze_indexes or analyze_slow_queries. No exclusions or prerequisites are mentioned.
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 must cover behavioral traits. It correctly notes that ANALYZE executes the query and is only allowed for SELECT queries. However, it does not disclose potential performance impact, resource consumption, or permissions needed, which are important for a SQL execution 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?
Two sentences efficiently convey the core purpose and key optional behavior. No unnecessary words or repetition. Front-loaded with the primary action.
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 output schema and 3 parameters, the description covers the main functionality but lacks details on the return format, timeout configuration (beyond default), and potential pitfalls. It is adequate but not comprehensive.
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 coverage is 100%, so the baseline is 3. The description adds context about output (formatted plan types), but does not enrich parameter meaning beyond what the schema already provides.
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?
Description clearly states the tool explains a SQL query with a formatted plan including cost estimates, node types, and optimization warnings. It distinctly sets the tool apart from siblings like analyze_slow_queries or suggest_missing_indexes by focusing on a single query execution plan.
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 use: running EXPLAIN on a SQL query, with an optional EXPLAIN ANALYZE for actual stats, restricted to read-only queries. It implicitly guides when to use the analyze flag, but does not explicitly contrast with sibling tools or mention when not to use it.
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 must convey behavioral traits. It states what information is returned but does not explicitly confirm it is read-only or mention potential performance impact on large schemas. While obviously non-destructive, the description lacks such explicit 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 sentence that efficiently conveys the two modes of operation. No extraneous words; it is front-loaded and easily scannable.
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?
The description covers the main return elements (row counts, sizes, columns, types, constraints, foreign keys). Although no output schema exists, this is sufficient for an agent to understand what to expect. It does not detail ordering or formatting, but that is acceptable for this tool's complexity.
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?
All parameters have descriptions in the schema. The description adds value beyond the schema: it explains that omitting 'table' lists all tables, and for 'timeout_ms' it advises increasing for slow/remote databases. This provides helpful context.
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: listing all tables with row counts and sizes, or inspecting a specific table's columns, types, constraints, and foreign keys. This distinguishes it from sibling tools which focus on performance analysis (indexes, slow queries, bloat, etc.).
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 does not provide explicit guidance on when to use this tool vs. alternatives, nor does it state when not to use it. However, the purpose is clear enough that an agent can infer it should be used for schema exploration before more specific analysis 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?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It describes what the tool detects but does not state whether it is read-only or has any side effects. The description is adequate but could be improved by explicitly noting the tool is non-destructive.
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 concise with three sentences. The first sentence states the purpose, the second elaborates on specific detections and database differences, and the third provides a constraint. No redundant or unnecessary information.
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 complexity of analyzing database connections, the description covers key detection items and database-specific limitations. However, the absence of an output schema means the agent must infer the return format, which could be clarified.
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 only parameter (timeout_ms) has a schema description that is clear, but the tool description adds additional context: 'Increase for slow or remote databases.' This provides practical usage advice beyond the 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 analyzes active database connections and lists specific detections (idle-in-transaction, lock contention, long-running queries, connection pool utilization). It also differentiates between PostgreSQL, MySQL, and SQLite, effectively distinguishing it from sibling tools like analyze_slow_queries.
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 explicit guidance on when not to use (MySQL/SQLite for certain features) and suggests using for PostgreSQL-specific blocking scenarios. However, it does not explicitly compare with alternatives like analyze_slow_queries or explain_query.
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?
Discloses reliance on specific system views, graceful handling of missing extension (returns setup instructions), and output contents. With no annotations, description covers key behavioral aspects adequately.
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?
Three sentences, under 60 words, front-loaded with purpose. Every sentence adds value; no redundancy.
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?
Covers purpose, database requirements, and high-level outputs. Lacks explicit mention of return format or pagination, but acceptable for a diagnostic tool with simple parameters.
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?
All three parameters are fully described in the input schema (100% coverage). Description adds no extra meaning beyond schema defaults and descriptions, so baseline of 3 is appropriate.
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?
Clearly states it finds slow queries using specific database extensions, shows execution times, counts, and recommendations. Distinct from sibling tools like analyze_indexes or explain_query.
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?
Provides clear context: available for PostgreSQL and MySQL, not for SQLite; PostgreSQL requires pg_stat_statements extension. Does not explicitly mention alternatives but siblings are listed.
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, the description fully handles behavioral disclosure. It explains the output (dependency graph, specific analyses) and the timeout parameter hints at potential long-running behavior. No contradictions.
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 packed with information without superfluous words. The first sentence immediately states the core action, and the second lists specific outputs.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having no output schema, the description fully details what the analysis produces. For the given complexity (2 parameters, no nested objects), the description is complete and leaves no ambiguity about the tool's capabilities.
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 input schema covers both parameters with descriptions, achieving 100% coverage. The description does not add additional meaning beyond the schema, so baseline score is appropriate.
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 it analyzes foreign key relationships and builds a dependency graph. It specifies exact outputs like orphan tables, cascading delete chains, hub entities, and circular FK dependencies, distinguishing it from siblings like analyze_connections or inspect_schema.
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 indicates the tool is useful for understanding schema design, planning migrations, and impact analysis. While it doesn't explicitly contrast with siblings, the context signals provide sibling names and the description implies appropriate use cases.
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:

[![mcp-db-analyzer MCP server](https://glama.ai/mcp/servers/Dmitriusan/mcp-db-analyzer/badges/card.svg)](https://glama.ai/mcp/servers/Dmitriusan/mcp-db-analyzer)

Score Badge

Copy to your README.md:

[![mcp-db-analyzer MCP server](https://glama.ai/mcp/servers/Dmitriusan/mcp-db-analyzer/badges/score.svg)](https://glama.ai/mcp/servers/Dmitriusan/mcp-db-analyzer)

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/Dmitriusan/mcp-db-analyzer'

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