mcp-oceanbase

Official

by oceanbase

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
Disambiguation4/5
Most tools have distinct purposes, such as configure_db_connection for setup, execute_sql for queries, and get_ob_ash_report for performance analysis. However, get_current_time and get_current_tenant could be confused as both retrieve basic system information, though their descriptions clarify the difference.
Naming Consistency4/5
The tool names follow a consistent verb_noun pattern with underscores, like configure_db_connection and execute_sql. A minor deviation is search_oceanbase_document, which uses 'search' instead of 'get' like other retrieval tools, but overall the naming is predictable and readable.
Tool Count5/5
With 8 tools, this server is well-scoped for OceanBase database management. The count is appropriate, covering configuration, query execution, monitoring, and documentation without being overwhelming or too sparse, allowing agents to handle core database tasks effectively.
Completeness3/5
The tool set covers key areas like connection setup, SQL execution, and monitoring (e.g., ASH reports, resource capacity), but there are notable gaps. Missing operations include data manipulation (e.g., insert, update, delete), schema management (e.g., create table), and user/tenant administration, which limits full database lifecycle coverage.
Average 3.2/5 across 8 of 8 tools scored. Lowest: 2.4/5.
See the Tool Scores section below for per-tool breakdowns.
- 0 of 1 community issues answered or closed in the last 6 months
- 1 commit in the last 12 weeks
- Last stable release on December 26, 2025
- 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. It describes the tool's function (searching documentation and providing context to the LLM) but lacks critical behavioral details: it doesn't mention whether this is a read-only operation, what format the retrieved information takes, potential rate limits, authentication needs, or how results are returned. The description is insufficient 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 moderately concise but could be more front-loaded. It starts with the purpose but includes redundant phrasing (e.g., repeating 'LLM' and 'OceanBase'). The bullet-point structure for functions is helpful, but some sentences (like the last one) are wordy and could be simplified without losing meaning.
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 complexity of a search tool with no annotations, no output schema, and 0% schema coverage, the description is incomplete. It explains the high-level workflow but misses key details: what the output looks like, error conditions, search scope limitations, or how the retrieved context is formatted for the LLM. For a tool that interacts with documentation, this leaves significant gaps.
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%, so the description must compensate. It mentions that 'the LLM should automatically extracts relevant search keywords' for the 'keyword' parameter, which adds some semantic context about how keywords should be derived. However, it doesn't explain what constitutes valid keywords, search syntax, or how the parameter affects results. With one undocumented parameter, this minimal explanation is inadequate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the tool 'searches through OceanBase-related documentation' and 'provides context-specific information about OceanBase', which gives a general purpose. However, it doesn't specify the exact resource being searched (e.g., 'documentation database', 'knowledge base') or distinguish it from potential documentation-related siblings. The purpose is clear but somewhat vague about the specific resource.
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 mentions using the tool 'when the LLM's internal documentation is insufficient', which provides some implied context. However, it doesn't explicitly state when to use this tool versus alternatives like execute_sql or get_ob_ash_report, nor does it provide clear exclusions or prerequisites. The guidance is minimal and lacks specificity.
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 but offers minimal behavioral insight. It implies execution of arbitrary SQL, but doesn't disclose critical traits like whether it's read-only or mutating, authentication requirements, transaction handling, error behavior, or rate limits. This leaves significant gaps for an agent to understand risks and outcomes.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise—a single sentence with no wasted words. It's front-loaded with the core action, though this brevity contributes to gaps in other dimensions. For length alone, it earns full marks for 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 complexity of SQL execution (potentially mutating, security-sensitive) with no annotations, 0% schema coverage, and no output schema, the description is highly incomplete. It lacks essential context on behavior, parameters, return values, and safety, making it inadequate for informed tool use.
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%, so the description must compensate but adds no parameter details. It mentions 'SQL' generically but doesn't explain the 'sql' parameter's format, supported SQL dialects, constraints (e.g., no multi-statement), or examples. This fails to address the undocumented parameter 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 action ('Execute') and target resource ('SQL on the OceanBase server'), making the purpose understandable. However, it doesn't differentiate this tool from potential sibling SQL execution tools (none are listed, but the generic nature doesn't address scope or limitations).
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. While sibling tools like 'configure_db_connection' or 'get_current_tenant' serve different purposes, the description doesn't clarify if this is for read-only queries, DML, DDL, or all SQL types, nor does it mention prerequisites like needing an established connection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden for behavioral disclosure. It describes what ASH samples (e.g., 1-second intervals, specific data points) and mentions usefulness for performance analysis, but lacks critical behavioral details: it doesn't specify if this is a read-only operation, potential performance impact, authentication requirements, rate limits, or error handling. For a tool with no annotation coverage, this leaves significant gaps in understanding how the tool behaves.
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 moderately concise but includes unnecessary content: 'RetryClaude can make mistakes. Please double-check responses.' is irrelevant and should be removed. The core explanation is front-loaded with the purpose, but the structure could be improved by directly linking parameters to the described functionality. It's not overly verbose but has wasted sentences.
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, 0% schema coverage, no output schema, and 3 parameters, the description is incomplete. It explains what ASH is and its utility but misses key contextual elements: parameter meanings, return format, behavioral constraints, and differentiation from sibling tools. For a performance analysis tool with complex inputs, this leaves too much undefined for effective agent use.
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%, so the schema provides no parameter descriptions. The description mentions 'ASH can sample... at 1-second intervals' but doesn't explain the three parameters (start_time, end_time, tenant_id) or their roles in filtering the report. It fails to compensate for the schema gap, leaving parameters undocumented in both schema and description.
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 OceanBase Active Session History report' with specific details about what ASH samples (SQL ID, wait events, wait time, module, SESSION status). It distinguishes this from siblings like execute_sql or search_oceanbase_document by focusing on performance analysis reports rather than direct SQL execution or documentation search. However, it doesn't explicitly contrast with get_all_server_nodes or get_resource_capacity which might also relate to performance monitoring.
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 with 'This will be very useful when you perform performance analysis,' suggesting it's for performance troubleshooting scenarios. However, it doesn't provide explicit guidance on when to use this tool versus alternatives like get_resource_capacity or execute_sql for performance insights, nor does it mention prerequisites or exclusions. The guidance is helpful but not comprehensive.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. 'Get current time' implies a read-only operation, but it doesn't specify whether it requires authentication, rate limits, timezone handling, or what format the output is in (e.g., string, timestamp). This leaves significant gaps 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description 'Get current time' is extremely concise—a single phrase with no wasted words. It's front-loaded and efficiently communicates the core purpose without unnecessary elaboration, making it ideal for quick understanding.
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 simplicity (0 parameters, no output schema, no annotations), the description is incomplete. It doesn't explain what 'current time' entails (e.g., timezone, format) or behavioral aspects like response type. For a tool with no structured data to rely on, 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 tool has 0 parameters, and schema description coverage is 100% (since there are no parameters to describe). With no parameters, the description doesn't need to add semantic details beyond what the schema provides, so a baseline of 4 is appropriate, as it adequately handles the lack of parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get current time' states a clear verb ('Get') and resource ('current time'), but it's vague about what 'current time' means (e.g., server time, UTC, local time) and doesn't distinguish from siblings like 'get_current_tenant' or 'get_all_server_nodes'. It avoids tautology by not restating the name exactly, but lacks specificity.
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 context (e.g., for timestamping operations) or exclusions, and there's no reference to sibling tools. Usage is implied only by the tool name, with no explicit instructions.
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 the current tenant name but doesn't describe what 'current' means in context (e.g., based on session, default, or active connection), whether it requires authentication, potential errors, or the format of the return value. This leaves significant gaps for an agent to understand how the tool behaves.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence with no wasted words. It's front-loaded with the core action and resource, making it easy to parse quickly. Every part of the sentence contributes directly to understanding the tool's purpose.
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 lack of annotations and output schema, the description is incomplete. It doesn't explain what the tool returns (e.g., a string, object, or error), how 'current' is determined, or any dependencies on other tools like 'configure_db_connection'. For a tool that likely interacts with a database system, more context is needed to use it effectively.
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 0 parameters, and schema description coverage is 100%, so there are no parameters to document. The description appropriately doesn't discuss parameters, which is correct for this case. A baseline of 4 is applied as it meets expectations without needing to compensate for any parameter gaps.
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 action ('Get') and the resource ('current tenant name from oceanbase'), making the purpose immediately understandable. However, it doesn't distinguish this tool from siblings like 'get_all_server_nodes' or 'get_resource_capacity' in terms of what specific information it retrieves versus other get operations.
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 prerequisites (e.g., whether a database connection must be configured first using 'configure_db_connection'), typical use cases, or relationships with sibling tools like 'execute_sql' that might also retrieve tenant information.
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 the sys tenant requirement, which is useful context about authentication needs. However, it lacks details on what 'resource capacity' entails (e.g., memory, CPU, storage), potential rate limits, error handling, or the format of the returned data, leaving significant gaps in transparency for a tool with no output schema.
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 brief with two sentences, making it efficient and front-loaded. However, the second sentence could be more integrated or structured for clarity, and there's some room for improvement in flow, but overall it avoids unnecessary verbosity.
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 complexity of retrieving system resource data, the description is incomplete. With no annotations and no output schema, it fails to explain what 'resource capacity' includes, the format of the return values, or any behavioral traits beyond the sys tenant requirement. This leaves the agent with insufficient information to understand the tool's full context and output.
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 that no inputs are required. The description doesn't add parameter information, which is acceptable in this case. Since there are no parameters, the baseline score is 4, as the description doesn't need to compensate for any gaps.
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 'resource capacity from oceanbase', making the purpose understandable. However, it doesn't differentiate this tool from sibling tools like 'get_all_server_nodes' or 'get_current_tenant', which also retrieve information from OceanBase, so it doesn't fully distinguish its specific scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides some usage context by stating 'You need to be sys tenant to get resource capacity', which implies a prerequisite for use. However, it doesn't explicitly state when to use this tool versus alternatives like 'get_all_server_nodes' or provide exclusions, leaving the guidelines somewhat implied rather than comprehensive.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses a key behavioral trait: the requirement to be a sys tenant, which is crucial for authentication. However, it lacks details on rate limits, error handling, or return format, leaving gaps 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 front-loaded with the core purpose in the first sentence and adds a critical prerequisite in the second. Both sentences earn their place by providing essential information without waste, though it could be slightly more structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations, no output schema, and low complexity (0 parameters), the description is minimally adequate. It covers the purpose and a key prerequisite but lacks details on return values or error cases, making it incomplete for full agent guidance.
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 0 parameters, and schema description coverage is 100%, so no parameter documentation is needed. The description appropriately doesn't discuss parameters, earning a baseline score of 4 for not introducing confusion or redundancy.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Get') and resource ('all server nodes from oceanbase'), making the purpose specific and understandable. It doesn't explicitly differentiate from siblings like 'get_resource_capacity', but the resource focus is distinct enough for clarity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides an implied usage guideline by stating 'You need to be sys tenant to get all server nodes', which indicates a prerequisite context. However, it doesn't explicitly mention when to use this tool versus alternatives like 'get_resource_capacity' or 'get_current_tenant', leaving some ambiguity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It effectively describes the tool's behavior: how it retrieves configuration from environment variables when parameters aren't provided, the fallback defaults, which parameters are required, and what error occurs when requirements aren't met. It doesn't mention rate limits, authentication needs beyond parameters, or what happens to the connection after retrieval, but covers the core operational behavior well.
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 and appropriately sized. The first paragraph establishes the purpose and usage guidelines, followed by clear parameter documentation. While the parameter documentation section is detailed, every sentence earns its place by providing essential information not available elsewhere. The structure is logical and front-loaded with the most important 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 (5 parameters, no annotations, no output schema), the description provides comprehensive coverage. It explains the tool's purpose, usage scenarios, all parameters with their semantics, return value format, and error conditions. The only minor gap is not explicitly describing the structure of the returned dictionary, but this is reasonable given the tool's scope and the absence of an output schema.
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?
With 0% schema description coverage, the description fully compensates by providing detailed semantic information for all 5 parameters. Each parameter is clearly explained with its purpose, default values, and environment variable fallbacks. The description adds significant value beyond the bare schema by clarifying which parameters are required and how the system prioritizes different input sources.
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: 'Retrieve OceanBase database connection information.' It specifies the exact action (retrieve) and resource (database connection information), distinguishing it from sibling tools like execute_sql or get_all_server_nodes that perform different operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance on when to use this tool: 'If no parameters are provided, the configuration is loaded from environment variables. Otherwise, user-defined connection parameters will be used.' This clearly explains the two usage scenarios and distinguishes it from alternatives by focusing on connection configuration rather than query execution or monitoring.
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:

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

Score Badge

Copy to your README.md:

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

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