ArcadeDB Multi-Model DBMS

Official

by ArcadeData

Overview Schema Related Servers Score Discussions

Hybrid

Server Quality Checklist

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

Latest release: v26.8.1
Disambiguation5/5
Each tool targets a clearly distinct concern: server admin (status, settings), profiler lifecycle (start/stop/status), and database operations (list, schema, query, execute). No two tools overlap in purpose, making misselection unlikely.
Naming Consistency4/5
Tools follow a consistent verb_noun pattern: profiler_start/stop/status, get_server_settings, set_server_setting, list_databases, get_schema, execute_command, query, server_status. The only slight deviation is 'execute_command' and 'query' which use more generic verbs rather than a resource-specific noun, and 'server_status' uses a different word order than get_/set_ prefixes.
Tool Count5/5
Ten tools is well-scoped for a DBMS server MCP. Each tool maps to a meaningful operation a client would need: server introspection, config management, profiling, and database CRUD/querying. Nothing feels redundant or missing at the top level.
Completeness4/5
The surface covers server status, configuration management, profiling, database enumeration, schema retrieval, and both read and write operations. Minor gaps include no database creation/deletion and no explicit way to retrieve saved profiler results from disk, but the core admin+query workflow is complete.
Average 4/5 across 10 of 10 tools scored. Lowest: 3.2/5.
See the Tool Scores section below for per-tool breakdowns.
- 703 of 705 community issues answered or closed in the last 6 months
- 1484 commits in the last 12 weeks
- Last stable release on August 3, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is failing
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.
This repository includes a glama.json configuration file.
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

Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. The description discloses what information is returned (types, properties, indexes, inheritance), which is useful. However, it doesn't disclose whether this is a read-only operation, the granularity of the schema output, or how the inheritance hierarchy is presented. It's a reasonable disclosure but not rich.
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 a single sentence that front-loads the core purpose and enumerates the specific contents of the schema. There's no wasted text. Could add usage guidance but is appropriately concise for what it covers.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The database schema retrieval is a moderately complex operation involving multiple data types and hierarchy, but the description covers the content scope well. However, with no output schema and no annotations, the agent has no idea about the structure or size of the returned schema. The description is adequate but could benefit from noting ordering, nesting depth, or related context.
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 a single parameter (database), and the schema description for 'The name of the database' is already sufficient. The description doesn't add much beyond this, but with a single well-documented parameter there's little to add. Baseline 3 is appropriate.
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), resource (schema of a database), and specifically enumerates what the schema includes (types, properties, indexes, inheritance hierarchy). It's distinct from siblings like list_databases (which lists DBs) and query (which runs queries). Could be slightly sharper in differentiating but is precise and specific.
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 doesn't provide any guidance on when to use this tool versus alternatives. It doesn't mention that this is a read-only introspection call, whether it requires specific permissions, or contrast with tools that might provide partial schema info. No when/when-not guidance given.
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 full burden for behavioral disclosure. The description is a read-only operation (listing databases) with no side effects implied. It identifies that results are scoped to the authenticated user, which is useful context. However, it doesn't disclose return format, potential pagination, ordering, or error conditions (e.g., unauthenticated, no databases), which would be valuable given no annotations exist.
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, complete sentence with zero wasted words. It states verb, resource, and scope efficiently. There is nothing superfluous and the information density is high for the tool's simplicity.
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 zero-parameter list operation, the description covers the essential semantics. However, given there is no output schema and no annotations, the description could have noted the return structure, whether it includes database URLs, sizes, or just names, and any authentication requirements. For such a simple tool, the description is mostly sufficient but leaves some gaps around what exactly is returned.
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% (trivially, since there are no params). The description states the scope ('available to authenticated user'), which adds semantic meaning about what is returned. With zero parameters, the baseline of 4 applies, and the description appropriately doesn't need to elaborate further.
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 uses a specific verb ('List') with resource ('all databases') and scope ('available to the authenticated user'), and explicitly names the server (ArcadeDB). It clearly distinguishes this from siblings like get_schema or query which operate on database contents rather than the database list itself. A small deduction for not distinguishing from potential 'create database' or 'drop database' siblings, but given the provided siblings, the purpose is clear.
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 this is for enumerating databases, useful before connecting to or selecting one. However, it doesn't explicitly state when to use this vs alternatives, nor mention prerequisites (e.g., needing authentication first). There are no exclusions or alternative tool mentions. It provides minimal but adequate context for the primary use case, though it lacks explicit guidance.
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 must fully disclose behavior. It indicates a read operation ('Get') but does not mention any side effects, authentication needs, or rate limits. For a simple info retrieval this is acceptable but insufficient for full 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, focused sentence that lists key details. It is front-loaded and concise with no wasted 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 the tool has no parameters and no output schema, the description is fairly complete. It specifies the type of information returned. Could be improved by hinting at the output format or structure, but it suffices.
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?
There are no parameters, so the input schema is fully covered. The baseline for 0 parameters is 4, and the description adds meaning by explaining what information is retrieved, which goes beyond the empty 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 retrieves server information, listing specific details like version, server name, query languages, and HA/cluster status. This differentiates it from sibling tools such as 'get_server_settings' or 'list_databases'.
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 server status but does not explicitly state when to use vs alternatives or provide exclusions. No guidance on when not to use.
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?
The description states read-only and idempotent behavior, which are key traits. However, with no annotations, more details about error handling or limitations would improve 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?
Two sentences, no fluff, front-loaded with purpose. Every part is valuable and efficiently conveyed.
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?
Adequate for a query tool with 4 parameters and no output schema. Could be improved by mentioning return format or common usage patterns, but is sufficient.
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 baseline is 3. The description adds context about query purpose and language preference, but does not significantly enhance parameter understanding 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 executes read-only queries on ArcadeDB, specifying the verb and resource. It distinguishes itself from sibling tools like execute_command by focusing on read operations.
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?
Explicitly instructs to use for SELECT, MATCH, and other read operations, and recommends preferring OpenCypher unless SQL is requested. This provides clear context for when to use this tool, though it does not explicitly mention exclusions.
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 transparently states that the tool returns whether the profiler is recording and includes profiling results if available. It implies a read-only operation with no side effects, which is sufficient for this simple getter.
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, front-loaded with the main purpose, and every word adds value. No wasted content.
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 parameters and no output schema, the description adequately explains what the tool returns. It covers all essential aspects for a simple status check, though could potentially mention that the profiler must be enabled.
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 no parameters, so the description does not need to add meaning beyond the schema. According to guidelines, 0 parameters baseline is 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description starts with 'Get the current status of the query profiler,' clearly stating the verb and resource. It distinguishes from sibling tools like profiler_start and profiler_stop by focusing on status retrieval, and from server_status by specifying profiler-specific details.
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 does not provide any guidance on when to use this tool versus alternatives such as profiler_start, profiler_stop, or server_status. No explicit context or exclusions are given.
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, description discloses key behavioral traits: changes take effect immediately, may not persist across restarts. This goes beyond the schema and provides useful runtime behavior context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, no filler. First sentence states action and effects; second sentence provides a usage tip. Well-structured and 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?
Adequate for a simple two-parameter tool with no output schema. Mentions persistence behavior but does not cover error conditions or authorization needs. Could be more 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%, so baseline is 3. Description gives example key values but does not add significant meaning 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?
Clearly states 'Update a server configuration setting at runtime', which is a specific verb (update) and resource (server configuration setting). Distinguishes from sibling get_server_settings which is for reading.
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?
Explicitly advises 'Use get_server_settings first to see available settings and their current values', providing a clear prerequisite. Does not specify when not to use, but the guidance is adequate.
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 carries the full burden. It clearly states the tool stops profiling and returns data, and adds that results are saved to disk. However, it doesn't mention if the profiler state is reset or if repeated calls have any side effects.
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, front-loaded with the primary action and result, followed by additional detail. Every sentence provides value without 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?
Given no parameters or output schema, the description adequately explains what the tool does and the nature of its return value (aggregated statistics, saved to disk). It could mention if the data is cumulative or cleared, but overall it is sufficiently complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters exist (0 params, schema coverage 100%). The description adds no parameter semantics but is not required to. Baseline for 0 params is 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool stops the query profiler and returns captured data. It distinguishes from siblings like 'profiler_start' and 'profiler_status' by specifying the stop action and return of profiling data.
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 after starting the profiler but does not explicitly state when to use, prerequisites (e.g., profiler must be running), or alternatives. The guidance is only implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description adds value by noting that sensitive values are masked. It lacks other behavioral details like performance impact, but for a read-only tool this is acceptable.
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 two sentences, front-loads the purpose, and contains no unnecessary information.
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?
The description fully explains what the tool returns (values, defaults, descriptions) and the masking behavior. For a parameterless retrieval tool, it is complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has no parameters, so the description correctly has no parameter info. Baseline score of 4 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 specifies the verb 'Retrieve' and the resource 'ArcadeDB server configuration settings', and distinguishes it from siblings like 'set_server_setting' and 'server_status'.
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 states to use it 'to understand and diagnose server configuration', which provides clear guidance. It does not explicitly mention alternatives but the siblings are distinct enough.
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?
No annotations are provided, so the description carries full burden. It discloses that commands are non-idempotent and lists write operations, signaling side effects. However, it does not detail error handling, transaction behavior, or authorization requirements, which would enhance 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?
Two sentences: first defines purpose and side-effect, second gives usage guidance. No redundant or extraneous information. Every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers purpose, usage, and parameter guidance adequately. However, without an output schema, it omits information about return values or error handling. For a write operation, explaining what the command returns (e.g., success indicator or affected records) 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?
Schema coverage is 100%, so baseline is 3. The description adds value by recommending the default language ('cypher') and when to use SQL, providing guidance beyond the schema. Other parameters are adequately described in 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 executes non-idempotent commands against an ArcadeDB database and lists write operations like INSERT, UPDATE, DELETE, CREATE TYPE. It distinguishes from sibling tools such as 'query' by specifying that this tool is for write 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?
Explicitly states when to use: for INSERT, UPDATE, DELETE, CREATE TYPE, and other write operations. Also provides guidance to prefer OpenCypher (cypher) unless SQL is explicitly requested, helping the agent select the appropriate language.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description fully discloses behavior: it records all queries with execution times and plans, auto-stops after timeout, and provides instructions for manual stop and status checks.
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 concise sentences: first states purpose, second details behavior, third provides usage guidance for siblings. No superfluous information.
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?
Given one optional parameter and no output schema, the description covers all necessary aspects: start, auto-stop, manual stop, and status check. It is complete 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?
The sole parameter timeoutSeconds is fully described in the schema (including default, min, max). The description reinforces the default value but adds no new semantic meaning 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 verb ('Start') and resource ('query profiler') and captures query execution data. It distinguishes itself from siblings profiler_status and profiler_stop by focusing on initiation.
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 explicitly mentions when to use alternatives: 'Use profiler_stop to stop early and get results, or profiler_status to check progress.' It also explains the auto-stop behavior.
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:

[![arcadedb MCP server](https://glama.ai/mcp/servers/ArcadeData/arcadedb/badges/card.svg)](https://glama.ai/mcp/servers/ArcadeData/arcadedb)

Score Badge

Copy to your README.md:

[![arcadedb MCP server](https://glama.ai/mcp/servers/ArcadeData/arcadedb/badges/score.svg)](https://glama.ai/mcp/servers/ArcadeData/arcadedb)

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/ArcadeData/arcadedb'

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