Doris MCP Server

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: v1.0.0
Disambiguation5/5
Each tool has a clearly distinct purpose with no ambiguity. exec_query handles SQL execution, get_db_list retrieves database names, get_db_table_list lists tables, get_recent_audit_logs fetches logs, and the remaining tools (get_table_column_comments, get_table_comment, get_table_indexes, get_table_schema) each target specific table metadata aspects without overlap.
Naming Consistency5/5
All tools follow a consistent verb_noun pattern using snake_case. The naming is highly predictable: exec_query, get_db_list, get_db_table_list, get_recent_audit_logs, get_table_column_comments, get_table_comment, get_table_indexes, and get_table_schema all adhere to the same convention.
Tool Count5/5
With 8 tools, this server is well-scoped for database interaction and metadata exploration. Each tool earns its place by covering distinct aspects like query execution, database/table listing, audit logs, and detailed table metadata, without being overly sparse or bloated.
Completeness4/5
The toolset provides strong coverage for querying and inspecting databases, including CRUD-like operations via exec_query and comprehensive metadata retrieval. Minor gaps exist, such as no explicit tools for creating/dropping databases or tables, but agents can work around this using exec_query for such operations.
Average 3/5 across 8 of 8 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- 11 of 11 community issues answered or closed in the last 6 months
- 110 commits in the last 12 weeks
- Last stable release on August 1, 2026
- 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?
No annotations are provided, so the description carries full burden for behavioral disclosure. It states this is a 'Get' operation (implying read-only), but doesn't mention authentication requirements, rate limits, error conditions, or what format the comment information returns. For a tool with no annotation coverage, this leaves significant behavioral gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description uses a structured format with sections, which helps organization. However, the '[Function Description]' and '[Parameter Content]' labels add unnecessary verbosity. The content itself is reasonably concise, but the formatting could be more streamlined without losing clarity.
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, no output schema, and 0% schema description coverage, the description is incomplete. It covers basic purpose and parameters but lacks crucial information about return format, error handling, and behavioral constraints. For a database query tool with siblings providing related functionality, more context is needed for effective use.
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 0%, so the description must compensate. It provides parameter information in the '[Parameter Content]' section, explaining what 'table_name' and 'db_name' represent. However, it doesn't clarify format expectations (e.g., case sensitivity, quoting requirements) or provide examples. The description adds meaningful semantics but doesn't fully compensate for the 0% schema coverage.
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 comment information for all columns in the specified table.' This is a specific verb ('Get') + resource ('comment information for all columns') combination. However, it doesn't explicitly distinguish this from its sibling 'get_table_comment' (which presumably gets table-level rather than column-level comments), so it misses the highest score.
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. With siblings like 'get_table_schema' and 'get_table_comment' that might provide related information, there's no indication of when column comments specifically are needed or when other tools might be more appropriate. The only implicit context is the parameter descriptions.
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 of behavioral disclosure. It states the tool retrieves comment information, implying a read-only operation, but doesn't clarify permissions, rate limits, error handling, or output format. For a tool with zero annotation coverage, this is a significant gap in transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is structured with labeled sections ('[Function Description]' and '[Parameter Content]'), which aids readability. However, it includes redundant formatting (e.g., brackets) and could be more streamlined. The content is front-loaded with the core purpose, but the parameter section adds necessary detail without being overly verbose.
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 the tool's complexity (2 parameters, no annotations, no output schema), the description is incomplete. It explains what the tool does and the parameters, but lacks critical context: it doesn't describe the return value (e.g., comment text format), error conditions, or how it differs from siblings. This leaves gaps for effective agent use.
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 description includes a '[Parameter Content]' section that lists both parameters with brief explanations: 'table_name' as required for the table to query, and 'db_name' as optional with a default. However, schema description coverage is 0%, so the schema provides no additional details. The description compensates somewhat by explaining parameter roles, but lacks depth on formats or constraints.
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 the comment information for the specified table.' It uses a specific verb ('Get') and resource ('comment information for the specified table'), making the function unambiguous. However, it doesn't explicitly differentiate from sibling tools like 'get_table_column_comments' or 'get_table_schema', which reduces it from a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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. It doesn't mention sibling tools like 'get_table_column_comments' (for column-level comments) or 'get_table_schema' (for schema details), nor does it specify prerequisites or exclusions. This leaves the agent without context for tool 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?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states what the tool does but doesn't mention any behavioral traits such as permissions required, rate limits, whether it's read-only or has side effects, or what the return format looks like. This is a significant gap for a tool with zero annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is structured with sections for Function Description and Parameter Content, which is organized but includes unnecessary and incorrect parameter information. The Function Description sentence is clear, but the Parameter Content adds verbosity without value, reducing efficiency.
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 the tool's complexity (simple list operation) but lack of annotations and output schema, the description is incomplete. It doesn't explain what the return value includes (e.g., format, pagination) or address behavioral aspects like error handling. For a tool with no structured support, more context is needed to be fully helpful.
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 the schema fully documents the lack of parameters. The description incorrectly includes a parameter 'random_string' in the Parameter Content section, which contradicts the schema. However, since the baseline for 0 parameters is 4, and the description's error doesn't severely mislead about parameter usage (as the schema overrides it), it scores slightly above minimum.
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 a specific verb ('Get') and resource ('list of all database names on the server'), making it immediately understandable. However, it doesn't explicitly differentiate from sibling tools like 'get_db_table_list' or 'exec_query', which prevents a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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 'get_db_table_list' (which might list tables within a database) or other siblings. It lacks any context about prerequisites, exclusions, or comparative use cases, leaving the agent to infer usage.
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 retrieving logs for a 'recent period' with defaults, but doesn't cover critical aspects like whether this requires specific permissions, what format the logs are returned in, if there are rate limits, or how the tool handles errors. For a read operation with zero 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.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description uses a structured format with sections, which is helpful, but includes redundant labeling like '[Function Description]' and '[Parameter Content]' that add little value. The content itself is reasonably concise, but the formatting could be more streamlined without sacrificing clarity.
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?
For a tool with 2 parameters, no annotations, and no output schema, the description is incomplete. It covers basic parameter semantics but lacks information about return format, error handling, authentication requirements, and how it differs from sibling tools. Given the complexity of audit logs and the absence of structured metadata, more contextual guidance is needed.
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 description provides meaningful semantic context for both parameters ('days' as 'Number of recent days of logs to retrieve' and 'limit' as 'Maximum number of records to return'), including their defaults. With 0% schema description coverage, this fully compensates by explaining what each parameter controls beyond just their types, though it doesn't specify constraints like minimum/maximum values.
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 a specific verb ('Get') and resource ('audit log records for a recent period'), making it immediately understandable. However, it doesn't explicitly differentiate from sibling tools like 'exec_query' or 'get_db_list', which could also potentially retrieve audit data, so it doesn't reach the highest score.
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 'exec_query' for custom queries or other sibling tools for database metadata. It only describes what the tool does, not when it's the appropriate choice, leaving the agent to infer usage context.
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 of behavioral disclosure. It states the tool 'Get[s] a list' but doesn't clarify if this is a read-only operation, whether it requires specific permissions, how it handles errors, or what the return format looks like. For a tool with zero annotation coverage, this is a significant gap in behavioral context.
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 appropriately sized and structured with clear sections for function and parameters. It uses bullet points efficiently and avoids redundancy. However, the formatting with brackets like '[Function Description]' is slightly verbose, and the content could be more front-loaded with key usage information.
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 low complexity (1 optional parameter, no output schema, no annotations), the description is minimally adequate. It covers the purpose and parameter semantics but lacks behavioral details, usage guidelines, and output information. For a simple read operation, this is borderline viable but leaves gaps in 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?
With 0% schema description coverage, the description compensates well by explaining the single parameter's semantics. It specifies that 'db_name' is the 'Target database name' and defaults to 'the current database', adding meaningful context beyond the schema's basic type and title. This is sufficient for the one parameter, though more detail on format or constraints could be helpful.
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 a specific verb ('Get') and resource ('list of all table names in the specified database'). It distinguishes itself from siblings like get_db_list (which lists databases) and get_table_schema (which provides schema details), though it doesn't explicitly name these alternatives. The purpose is unambiguous but could be slightly more specific about differentiation.
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. It doesn't mention siblings like get_db_list for listing databases or get_table_schema for detailed table information, nor does it specify prerequisites or contexts for usage. This leaves the agent without clear direction on tool 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 of behavioral disclosure. It states the tool 'queries' index information, implying a read-only operation, but doesn't clarify permissions, rate limits, error conditions, or what the output format looks like. This is a significant gap for a tool with no annotation coverage.
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 appropriately sized and front-loaded with the function description, followed by parameter details. It uses a structured format with bullet points, making it easy to parse, though the bracketed headings add minor verbosity.
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 annotations, no output schema), the description covers the basic purpose and parameters adequately. However, it lacks details on output format, error handling, or behavioral constraints, making it incomplete for optimal agent use without additional context.
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 description adds meaningful semantics for both parameters: it specifies that table_name is required for querying and db_name is optional with a default to the current database. With 0% schema description coverage, this compensates well by providing clear parameter roles and defaults beyond the basic schema.
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 as 'Get index information for the specified table,' which is a specific verb+resource combination. However, it doesn't explicitly differentiate from sibling tools like get_table_schema or get_table_column_comments, which might retrieve related but different metadata.
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. It doesn't mention sibling tools like get_table_schema or explain what makes this tool unique for index information, leaving the agent to infer usage from context 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 the full burden of behavioral disclosure. It states it 'gets' information, implying a read-only operation, but doesn't specify whether this requires permissions, has rate limits, returns paginated results, or what format the output takes (e.g., JSON, structured data). For a tool with no annotation coverage, this leaves significant gaps in understanding how it behaves beyond basic functionality.
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 appropriately sized and structured with clear sections for function and parameters. Each sentence adds value: the first defines the purpose with examples, and the parameter section explains semantics. There's minimal waste, though the formatting with brackets and bullet points is slightly verbose but still efficient.
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 purpose and parameter semantics adequately, but lacks behavioral details like output format, error handling, or usage guidelines relative to siblings. Without annotations or output schema, more context on what 'detailed structure information' entails would improve 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 description adds meaningful context beyond the input schema, which has 0% description coverage. It explains that table_name is required and specifies what it queries, and clarifies that db_name is optional with a default to the current database. This compensates well for the lack of schema descriptions, though it doesn't detail constraints like valid table name formats or database name syntax.
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 the resource 'detailed structure information of the specified table', with specific examples like 'columns, types, comments, etc.' This distinguishes it from siblings like get_db_list or get_table_indexes by focusing on comprehensive schema details rather than lists or specific components. However, it doesn't explicitly differentiate from get_table_column_comments or get_table_comment, which are more specialized siblings.
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. It doesn't mention siblings like get_table_column_comments (for only comments) or get_table_indexes (for indexes), nor does it specify prerequisites such as needing database access or when this is preferred over exec_query for schema inspection. Usage is implied by the purpose but lacks explicit context or exclusions.
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 that results are 'returned' and 'executed by the client,' but lacks critical details: whether queries are read-only or can modify data, authentication requirements, error handling, result format, or any rate limits. For a SQL execution tool with zero annotation coverage, this leaves significant behavioral gaps unaddressed.
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 well-structured with clear sections ([Function Description] and [Parameter Content]) and uses bullet points efficiently. Every sentence earns its place by providing essential information. It could be slightly more concise by integrating the sections more fluidly, but overall it's appropriately sized and front-loaded with the core purpose.
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 complexity of a SQL execution tool, no annotations, and no output schema, the description is moderately complete. It covers parameters thoroughly but lacks behavioral context (safety, permissions, result format) and doesn't explain what 'return result command' means or how results are structured. For a tool that could potentially modify data, this leaves important gaps despite good parameter documentation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/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 fully compensate. It does this excellently by providing clear semantics for all 4 parameters: sql (required SQL statement), db_name (optional target database with default behavior), max_rows (optional row limit with default), and timeout (optional timeout with default). Each parameter's purpose, optionality, and defaults are clearly explained beyond what the bare schema provides.
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: 'Execute SQL query and return result command (executed by the client).' This specifies the verb ('Execute SQL query') and resource ('SQL query'), distinguishing it from sibling tools that are all read-only metadata retrieval functions (like get_db_list, get_table_schema). However, it doesn't explicitly contrast with those siblings beyond the different action.
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. It doesn't mention that siblings are for metadata retrieval while this is for actual query execution, nor does it discuss prerequisites like database connectivity or permissions. The only implicit usage context is that it executes SQL, but no explicit when/when-not instructions are provided.
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:

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

Score Badge

Copy to your README.md:

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

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/doris-mcp-server'

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