existdb-mcp

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: documentation lookup, namespace listing, searching, and data operations are separated without overlap. Even the two list tools differ by scope (functions in a namespace vs. all namespaces), and delete_resource explicitly covers both documents and collections.
Naming Consistency5/5
All tool names follow the pattern 'existdb_<verb>_<object>' using snake_case, with verbs like lookup, list, search, get, execute, validate, store, delete, and create. This uniform convention makes the tool set predictable and easy to navigate.
Tool Count5/5
With 12 tools, the server is well-scoped for an eXist-db MCP, covering both documentation lookup and essential XML database operations. The count is appropriate and neither too sparse nor bloated.
Completeness5/5
The tool set provides comprehensive coverage of the eXist-db domain: documentation (lookup, list, search, snippets) and data management (create collection, store/get/list documents, delete, execute/validate XQuery). Store_document handles both create and replace, covering update operations without needing a separate tool.
Average 3.6/5 across 12 of 12 tools scored. Lowest: 2.8/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 0 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It only states the basic retrieval function and omits important details like authentication requirements (endpoint, username, password) or return format.
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 clear sentence that achieves conciseness and proper front-loading. It lacks additional detail, but the brevity is appropriate for the core purpose it conveys.
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 output schema, no annotations, and minimal parameter guidance, the description is insufficiently complete. It does not address error behavior, authentication, or return structure, which is necessary for safe and correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 25% (path only), and the tool description adds no parameter meaning. It does not mention that endpoint, username, and password are needed for connection, leaving a significant gap.
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 action ('Retrieves') and the resource ('XML content of a document stored in eXist-db'), making it distinct from sibling tools like store_document or delete_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?
No guidance is provided on when to use this tool versus alternatives. The description does not mention scenarios, exclusions, or related tools, leaving the agent without contextual selection cues.
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?
Since no annotations are provided, the description carries the full burden of disclosing behavioral traits. It clearly states 'deletion is permanent', which is a critical destructive characteristic. However, it does not disclose other relevant behaviors such as authentication requirements, whether collection deletion is recursive, or what happens on failure. The permanent-deletion warning provides meaningful transparency but leaves gaps.
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: the first states the action and target, the second provides a critical warning. Both are essential and free of fluff, making it appropriately concise and front-loaded.
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 destructive operation with four parameters and no output schema, this description is inadequate. It does not explain auth parameters, the need for an endpoint, or the behavior when deleting a collection (e.g., non-empty). Given the complexity and the lack of rich schema/annotations, the description is incomplete for an agent to invoke the tool confidently.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 25% (only 'path' is described), and the description adds no parameter semantics. It does not explain the 'endpoint', 'username', or 'password' parameters, nor their roles in the deletion. The description contributes nothing beyond the schema's minimal path description, failing to compensate for the low coverage.
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 states a specific verb ('Deletes') and resource ('document or collection from eXist-db'), clearly distinguishing it from sibling tools that list, search, store, or execute. The name and description align perfectly, leaving no ambiguity about the tool's function.
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 only warns 'Use with caution' but provides no guidance on when to use this tool versus alternatives (e.g., when a collection is non-empty, or the need for prerequisites like authentication). It does not mention any exclusions or specific user scenarios, so the usage guidance is minimal.
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 carry the full burden. It discloses authentication requirements but does not warn that XQuery execution may have side effects (updates/deletions), nor does it mention error behavior. Arbitrary code execution is a significant behavioral trait left unmentioned.
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, front-loaded with the primary action. No redundant language; achieves the purpose quickly and edits cleanly.
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 an 8-parameter tool with no output schema or annotations, the description is sparse. It omits return format, pagination behavior, error handling, and safety considerations. The schema explains parameter details but not the execution environment or when to use this vs sibling tools.
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% for all 8 parameters, so the baseline is 3. The description only echoes the endpoint/username/password params without adding semantics on max/start pagination or collection context, which are already covered 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 verb 'Executes' and the resource 'XQuery expression against a live eXist-db instance via the REST API', distinguishing it from sibling tools that validate or lookup functions. It's specific and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No when-to-use or alternative guidance is given. It only states prerequisites (env vars/direct params). There is no mention of using existdb_validate_xquery for validation or existdb_search_functions for search, which are natural alternatives.
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, the description carries the full burden of behavioral disclosure. It does not mention authentication requirements (endpoint, username, password are in the schema but not described), behavior if the collection already exists, error conditions, or return values. The only behavioral hint is that the parent must pre-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 one concise sentence with no redundant details. It directly states the operation with no filler, making it easy to parse quickly.
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?
With 5 parameters (3 without schema descriptions), no annotations, and no output schema, the description is not complete enough. It omits authentication requirements, error behavior, and return semantics, which are critical for an agent to invoke the tool correctly.
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 only 40% (name and parent have descriptions). The description adds that the parent is existing and the new item is a sub-collection, but it says nothing about the endpoint, username, or password parameters, leaving them completely undocumented. It does not sufficiently compensate for the low schema coverage.
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 states a specific action (creates) and a specific resource (a new sub-collection inside an existing eXist-db collection). This clearly distinguishes it from sibling tools like existdb_list_collection or existdb_get_document, which 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 Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'inside an existing eXist-db collection' implies a prerequisite: the parent collection must already exist. However, it does not explicitly guide when to use this tool versus alternatives (e.g., creating a collection vs. storing a document), nor does it mention any exclusions or alternative tool names.
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 gives a clear read-only indication via 'Lists' and specifies the returned metadata, but does not mention authentication requirements, error behavior, or explicitly state that it has no side effects. With no annotations, this leaves some behavioral uncertainty.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that conveys the essential action and return details without unnecessary words.
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?
While the description clearly explains the tool's main purpose and output, it lacks essential context about authentication parameters (username/password), the meaning of 'endpoint', and prerequisites, making it incomplete for a 4-parameter tool with no annotations or output schema.
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?
Only the 'path' parameter has a description in the schema; the tool description adds no information about 'endpoint', 'username', or 'password'. Since schema coverage is only 25%, the description fails to compensate for the undocumented parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Lists the contents of an eXist-db collection') and specifies the output (sub-collections and XML documents with metadata), distinguishing it from sibling tools that handle functions, queries, or single documents.
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; the description only states what it does without mentioning any exclusions or alternative tools for related tasks.
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 must disclose behavior. It does state the operation creates or replaces a document, which implies overwriting existing files, and mentions the HTTP PUT method. However, it does not disclose authentication requirements (username/password), error handling for invalid XML, or the return/response format, leaving important 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single sentence containing the essential verb, resource, and method without redundancy. Front-loaded and efficient, earning a high score.
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 a 6-parameter tool with no annotations and no output schema, this bare description is insufficient. It omits authentication context (endpoint/username/password), does not explain the consequences of replacing an existing document beyond the word 'replaces,' and lacks any guidance on error conditions or response. The description does not fully equip an agent to invoke the tool correctly.
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 only 50% (content, filename, collection have descriptions; endpoint, password, username do not). The tool description adds no information about any parameters—it doesn't explain what collection, filename, content, or auth fields are needed. It merely restates the document type (XML), which the schema already provides. With no compensation for the undocumented parameters, this scores low.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Stores' with parenthetical 'creates or replaces' to clarify the write semantics, identifies the resource (XML document in an eXist-db collection), and notes the HTTP method PUT. This clearly distinguishes it from sibling tools like get/delete/execute.
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 a use case (storing documents into eXist-db) but provides no explicit guidance on when to choose this tool over siblings, no exclusions, and no mention of prerequisites like authentication or collection creation. It would benefit from saying 'Use this to upload or overwrite documents; see create_collection for creating collections.'
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It correctly implies a read-only operation ('Returns') and mentions the data source ('documentation cache'), but does not disclose potential edge cases, such as whether the filter parameter affects the summary, or any performance or caching behavior. The description adds some context but lacks richness in explaining side effects or limitations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that is front-loaded with the action ('Returns'), concisely states the resource, and includes the two key attributes (prefix and count). Every word earns its place; there is no redundancy or tangential 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?
For a simple read-only tool with one optional parameter and no output schema, the description covers the essential return features (summary table, prefix, count) and the data source. It does not explicitly mention the optional filter, but the schema covers that. It lacks explicit usage context and mentions no limitations, but the tool is simple enough that completeness is high.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% for the single 'filter' parameter, with detailed enum descriptions for each category. The tool description does not add any parameter-specific information beyond the schema, so it does not improve on the existing semantics. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns a summary table of all available namespaces in the documentation cache, including prefix and count of documented functions. It uses a specific verb ('Returns') and a specific resource ('namespaces'), and it distinguishes itself from sibling tools like existdb_list_namespace_functions, which likely lists functions for a given namespace.
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 gives no guidance on when to use this tool versus alternatives, nor does it mention exclusions or prerequisites. It is purely descriptive without contextual 'when' or 'when not' guidance. Sibling tools are not referenced, so the agent is left to infer appropriate usage from the purpose alone.
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 carries the full burden of disclosing behavior. It explains that the tool returns a ready-to-use snippet and lists topics, but it does not mention side effects, error handling, or the exact output format beyond 'ready-to-use'. This is adequate 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences: the first states the primary purpose, the second enumerates valid topics. No redundant or filler content; the tool's behavior is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter snippet getter, the description covers the supported topics and the nature of the output. There is no output schema, but the description explicitly says it returns a snippet, which is sufficient for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% and the description's topic list mirrors the schema's parameter description, so the description adds no new meaning beyond what the schema already provides. Baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Returns' and the resource 'XQuery code snippet', and the topic list makes the tool's scope concrete. This distinguishes it from sibling tools like existdb_execute_query (which runs queries) and existdb_get_document (which retrieves documents).
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 available topics give useful context for what the tool can provide, but the description does not explicitly state when to use this tool over alternatives or when not to use it. Usage is implied rather than directly guided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. It discloses that only documented functions are listed (a filtering behavior) and implies a read-only operation. However, it does not explicitly state side-effect-free behavior, error scenarios, or any limitations beyond 'documented'.
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-loads the core action, and then gives concrete input examples. Every word adds value, with no redundant or vague phrasing.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple single-parameter list tool, the description sufficiently explains the purpose and input format. It does not describe the return value format, but the tool name and description ('Lists all documented functions') imply the output is a list, so it is largely complete. A small gap: no mention of what happens for an unknown/invalid namespace.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already has 100% coverage with a clear description and examples. The tool description adds the phrase 'conventional prefix' and more prefix examples, but these largely overlap with the schema. It does not add significant new meaning beyond what the schema provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists all documented functions in a specified eXist-db / XQuery namespace. It uses a specific verb ('Lists') and resource ('documented functions in a given namespace'), which distinguishes it from siblings like existdb_list_namespaces or existdb_lookup_function.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context on when to use this tool: when you need a full list of functions in a namespace. It gives examples of valid inputs ('xmldb', 'ft', 'util', 'sm', 'fn'), but it does not explicitly mention alternatives or exclusions such as 'use existdb_lookup_function to search for a specific function'.
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 full burden. It discloses key behaviors: it validates against a live instance, does not execute, and returns syntax errors with line/column info. However, it omits details about authentication requirements, network dependency, and behavior on success, leaving some ambiguity.
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 concise sentences, front-loaded with the main purpose and immediately followed by the return value. Every word adds value, with no filler or repetition.
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 explains the tool's core function and error output, but lacks information about success response, connection parameters, and authentication. Given no output schema and no annotations, these gaps leave the tool underspecified for a user needing full operational context.
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 only 25% (only 'xquery' is described). The description does not compensate for the undocumented 'endpoint', 'password', and 'username' parameters, leaving their roles inferable only from names. The description adds no new semantic detail beyond the schema's own 'xquery' description.
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 a specific verb ('validates'), resource ('XQuery expression'), and context ('against a live eXist-db instance'), while explicitly contrasting with execution ('without executing it'). This distinguishes it from sibling tools like existdb_execute_query.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'without executing it' provides clear context that this tool is for syntax checking rather than executing a query, implying use cases. However, it does not explicitly name alternatives or state when not to use this tool, so it stops short of full guidance.
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 carries the full transparency burden. It clearly conveys a non-destructive search operation, but doesn't disclose return format, pagination, or any potential side effects, which would be valuable for an agent to know.
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 with no fluff, front-loads the key purpose, and every word contributes meaning.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple search tool with two parameters and no output schema, the description adequately explains the function's scope and usefulness. It could mention result behavior (e.g., returns matching function names) but that is not strictly necessary for a discovery tool.
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%, but the description enhances the meaning of 'keyword' by specifying it matches against function names and descriptions. This adds useful context beyond the schema examples.
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 performs a full-text search across eXist-db/XQuery function names and descriptions, which is specific and distinct from siblings like existdb_lookup_function that presumably handle exact lookups.
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?
It explicitly says the tool is useful when you know what you want to do but not the exact function name, providing clear context for when to use it. It doesn't explicitly mention alternatives or exclusions, but the sibling list makes the distinction obvious.
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 the full burden. It discloses the return content (full signature, parameter descriptions, return type, usage notes) and input flexibility (local, prefixed, or partial match). The read-only nature is implicit, and ambiguous partial-match behavior is not fully explained, but for a simple lookup tool this is adequate.
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, each adding distinct information: purpose, return detail, and input formats. There is no redundancy, fluff, or unnecessary detail. The most important information is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and no annotations, the description covers the essential aspects: what the tool does, what it returns, and how to specify the function name. It does not mention error behavior or explain the optional namespace usage beyond the schema, but for a straightforward lookup operation this is sufficient.
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 schema already describes both parameters fully (100% coverage), giving a baseline of 3. The description adds value by explaining that the name can be a partial match and that the tool can return one or more functions, which goes beyond the schema's simple examples.
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 a specific verb ('Look up') and resource ('documentation for eXist-db / XQuery functions'), and distinguishes from sibling tools by focusing on name-based lookup. It also specifies accepted name forms (local, prefixed, partial), making the tool's purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear usage context: this tool is for looking up function documentation by name, with examples of accepted formats. However, it does not explicitly name alternatives like existdb_search_functions or state when not to use this tool, so it lacks explicit exclusions or when-not guidance.
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:

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

Score Badge

Copy to your README.md:

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

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