How do I use existdb-mcp?

1. Click on "Install Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@existdb-mcp List documents in /db/corpus modified this week" That's it! The server will respond to your query, and you can continue using it as needed. Here is a step-by-step guide with screenshots.

existdb-mcp

by orazionelson

Overview Schema Related Servers Score Discussions

TypeScript

Hybrid

existdb-mcp

An MCP (Model Context Protocol) server that connects Claude to eXist-db — the native XML database widely used in the digital humanities as the backbone of TEI Publisher, scholarly editions, linguistic corpora and institutional archives.

If you work with TEI/XML corpora, manage a DH project, or develop XQuery applications, this server lets Claude:

read your offline copy of the eXist-db function reference,
run XQueries against your live database,
inspect, retrieve, store and delete documents and collections —

all through natural-language prompts in Claude Code or Claude Desktop. No more context-switching between the chat, eXide and the REST endpoint.

What you get

📚 Offline documentation lookup — full signatures for every built-in function, served from a local cache of the eXist-db fundocs (no internet needed once scraped)
⚙️ Live XQuery execution — run queries against your eXist-db instance via the REST API, with paginated results
🗄️ Collection management — list, create, store, retrieve and delete collections and documents (think /db/corpus, /db/apps/edition, …)
🧠 XQuery snippets — ready-to-paste templates for common patterns (RESTXQ endpoints, Lucene full-text, XSLT pipelines, HTTP client, …)

Who is this for?

👩‍💻 XQuery / eXist-db developers building apps, RESTXQ APIs or data pipelines.
"Look up xmldb:store, then store this XML as /db/myapp/data/01.xml."
📜 Researchers & digital humanists working on TEI editions, corpora or critical editions.
"Extract all <persName> values from /db/corpus and return a frequency-ordered list."
🗂️ Archivists & curators managing XML-encoded collections (EAD, TEI, METS, EpiDoc, …).
"List every document in /db/archive/finding-aids modified in the last 30 days, with size and last editor."

Related MCP server: Local Development MCP Server

Quick start

1. Clone and install

git clone https://github.com/your-username/existdb-mcp.git
cd existdb-mcp
npm install

2. Build the documentation cache

This scrapes exist-db.org/exist/apps/fundocs and writes src/cache/fundocs.json:

npm run scrape

No internet, or want to try the server right away? Use the offline fixture instead — it ships a tiny but real cache so the documentation tools work out of the box:
npm run scrape -- --offline

3. Build the TypeScript

npm run build

The build step compiles src/ to dist/ and copies the documentation cache into dist/cache/ so the server can find it at runtime.

4. Try it

npm start
# > existdb-mcp running on stdio

The server speaks the MCP stdio protocol — point an MCP client at it (see below) to start using the tools.

Configuring Claude

Claude Code

Add to your project's .claude/mcp.json (or ~/.claude/mcp.json for a global install):

{
  "mcpServers": {
    "existdb": {
      "command": "node",
      "args": ["/absolute/path/to/existdb-mcp/dist/index.js"],
      "env": {
        "EXISTDB_ENDPOINT": "http://localhost:8080/exist",
        "EXISTDB_USER": "admin",
        "EXISTDB_PASSWORD": "your-password"
      }
    }
  }
}

Claude Desktop

Add to claude_desktop_config.json:

macOS: ~/Library/Application Support/Claude/claude_desktop_config.json
Windows: %APPDATA%\Claude\claude_desktop_config.json
Linux: ~/.config/Claude/claude_desktop_config.json

{
  "mcpServers": {
    "existdb": {
      "command": "node",
      "args": ["/absolute/path/to/existdb-mcp/dist/index.js"],
      "env": {
        "EXISTDB_ENDPOINT": "http://localhost:8080/exist",
        "EXISTDB_USER": "admin",
        "EXISTDB_PASSWORD": "your-password"
      }
    }
  }
}

Restart Claude Desktop / Claude Code and the existdb tools will appear in the available-tools list.

Tip — docs only, no eXist-db running? You can omit the env block entirely. The documentation tools work offline; only the query/collection tools require a live server.

Environment variables

Variable	Default	Description
`EXISTDB_ENDPOINT`	`http://localhost:8080/exist`	eXist-db base URL (no trailing `/rest`)
`EXISTDB_USER`	`admin`	eXist-db username
`EXISTDB_PASSWORD`	(empty)	eXist-db password

All three can also be passed inline as arguments to any tool call (endpoint, username, password) — useful when you want Claude to connect to a different instance for one-off queries.

Available tools

Documentation (offline — no eXist-db needed)

Tool	Description
`existdb_lookup_function`	Full docs for a function: signature, params, return type
`existdb_list_namespace_functions`	All functions in a namespace (e.g. `xmldb`, `ft`, `util`)
`existdb_search_functions`	Full-text search across function names and descriptions
`existdb_list_namespaces`	Summary table of all available namespaces
`existdb_get_xquery_snippet`	Ready-to-use XQuery snippet for a common pattern

Snippet topics: store-document, fulltext-search, restxq, http-client, security, transform-xslt, collection-query.

Query execution (requires a live eXist-db)

Tool	Description
`existdb_execute_query`	Execute an XQuery expression, returns paginated results
`existdb_validate_xquery`	Check XQuery syntax without executing

Collection management (requires a live eXist-db)

Tool	Description
`existdb_list_collection`	List sub-collections and documents in a collection
`existdb_get_document`	Retrieve the XML content of a document
`existdb_store_document`	Create or replace a document via PUT
`existdb_delete_resource`	Delete a document or collection
`existdb_create_collection`	Create a new sub-collection

Example prompts

Once connected to Claude, you can ask things like:

Discover the API

What parameters does xmldb:store accept?
List all functions in the Lucene full-text namespace.
Search for functions related to scheduling.
Show me a RESTXQ endpoint snippet.
What namespaces are available for security?

Query a live database

On my local eXist-db, run:
  for $doc in collection("/db/myapp")//record
  return $doc/title/string(.)

Validate this XQuery without running it:
  let $x := 1
  return $x +

Count how many documents are in /db/apps/dashboard.

Manage collections and documents

List the contents of /db/myapp/data.

Create a new collection called "drafts" inside /db/myapp.

Store this XML as /db/myapp/config/settings.xml:
  <settings><theme>dark</theme></settings>

Show me the contents of /db/myapp/config/settings.xml.

Delete the resource at /db/myapp/tmp/old-import.xml.

Combine the two

Look up xmldb:store, then use it to save
  <todo><item>Write tests</item></todo>
as /db/scratch/todo.xml.

Working with TEI corpora

If your collections contain TEI/XML, you can drive most of the day-to-day philological work straight from the chat.

Metadata from <teiHeader>

List the title, author and publication date for every document in
/db/corpus by reading the teiHeader.

Named entities

Extract all <persName> values from /db/corpus, deduplicate them and
return a frequency-ordered list.

Find every occurrence of <placeName ref="..."/> in /db/corpus/letters
and group them by the `ref` attribute.

Provenance and curation

Show me documents in /db/corpus that have been modified in the last 7
days, ordered by modification date.

Validate that every TEI file in /db/corpus has a non-empty
<sourceDesc>; list the offending paths.

Lightweight stylometry / text analysis

Count the occurrences of <said> per speaker across /db/corpus/plays
using the Lucene full-text index for speed.

Importing and exporting

Store this TEI fragment as /db/corpus/drafts/letter-042.xml:
  <TEI xmlns="http://www.tei-c.org/ns/1.0"> ... </TEI>

Apply /db/corpus/xslt/tei-to-html.xsl to
/db/corpus/letters/letter-001.xml and return the HTML.

Tip — for namespace-aware queries (every TEI document lives under xmlns="http://www.tei-c.org/ns/1.0"), ask Claude to declare declare default element namespace "http://www.tei-c.org/ns/1.0"; at the top of the XQuery. The model is happy to do this when you mention "TEI" in the prompt.

Ecosystem

A few projects you'll likely want next to this one:

TEI Publisher — the most common front-end for TEI editions on top of eXist-db
TEI Guidelines — the canonical reference for the encoding scheme
eXide — the in-browser IDE bundled with eXist-db; useful when Claude hands you a query you want to tweak by hand

Testing

The project ships with unit tests for the offline pieces (documentation lookup and config resolution). They use Node's built-in test runner, so there's no extra dependency:

npm test

Tests inject a small fixture cache directly, so you don't need to run the scraper or have an eXist-db instance up.

For end-to-end checks against a real database, the easiest path is:

# 1. Start eXist-db (Docker is the quickest)
docker run -d --rm -p 8080:8080 --name exist existdb/existdb:latest

# 2. Wait until http://localhost:8080/exist returns 200, then:
EXISTDB_PASSWORD=  node dist/index.js
# and exercise the tools through your MCP client

Troubleshooting

fundocs.json not found at …/dist/cache/fundocs.json The build step couldn't find the documentation cache. Run npm run scrape (or npm run scrape -- --offline for the fixture) and then npm run build again — the post-build step copies the cache into dist/.

Connection error: Cannot reach eXist-db at … The query/collection tools couldn't open a TCP connection. Check that:

eXist-db is running and reachable at EXISTDB_ENDPOINT
the URL has no trailing /rest (the server appends it automatically)
a firewall isn't blocking the port

Query error (HTTP 401) The credentials are wrong or missing. Set EXISTDB_USER / EXISTDB_PASSWORD, or pass username / password explicitly in the tool call. The default admin user has an empty password on a fresh install.

XQuery syntax error at line N, column M This is the eXist-db parser talking — the query has invalid XQuery. Use existdb_validate_xquery to iterate quickly without executing.

The server starts but Claude doesn't see the tools

Make sure the args path in your MCP config points to the compiled dist/index.js, not the TypeScript source
Restart Claude Code / Claude Desktop after editing the MCP config
Check Claude's MCP logs for stderr from the server

Regenerating the documentation cache

The cache is tied to the eXist-db version it was scraped from. Regenerate it whenever you upgrade or want fresher docs:

npm run scrape   # ~2–3 minutes, polite 300 ms delay between namespaces
npm run build

Project structure

existdb-mcp/
├── src/
│   ├── index.ts                  # MCP server entry point
│   ├── types/
│   │   └── index.ts              # Shared TypeScript types
│   ├── tools/
│   │   ├── docs.ts               # Documentation lookup tools
│   │   ├── query.ts              # XQuery execution tools
│   │   ├── query-helpers.ts      # Shared auth / config helpers
│   │   └── collections.ts        # Collection management tools
│   └── cache/
│       └── fundocs.json          # Generated by `npm run scrape`
├── scripts/
│   ├── scrape-fundocs.ts         # Fundocs scraper
│   └── copy-cache.mjs            # Post-build cache copy
├── test/
│   ├── fixtures.ts               # Deterministic fundocs fixture
│   ├── docs.test.ts              # Documentation tools tests
│   └── query-helpers.test.ts     # Config / auth helpers tests
├── dist/                         # Compiled output (npm run build)
├── package.json
├── tsconfig.json
└── README.md

Contributing

Issues and pull requests are welcome. Please run npm test and npm run build before submitting.

License

MIT — see LICENSE.

Available Tools

12 tools

existdb_create_collectionB

Creates a new sub-collection inside an existing eXist-db collection.

ParametersJSON Schema

Name	Required	Description
`name`	Yes	Name of the new sub-collection
`parent`	Yes	Parent collection path, e.g. '/db/myapp'
`endpoint`	No
`password`	No
`username`	No

TDQS

B3.3/5.0

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.

existdb_delete_resourceB

Deletes a document or collection from eXist-db. Use with caution — deletion is permanent.

ParametersJSON Schema

Name	Required	Description
`path`	Yes	Full path to the document or collection to delete
`endpoint`	No
`password`	No
`username`	No

TDQS

B3.1/5.0

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.

existdb_execute_queryB

Executes an XQuery expression against a live eXist-db instance via the REST API and returns the results. Requires EXISTDB_ENDPOINT, EXISTDB_USER, EXISTDB_PASSWORD env vars, or pass endpoint/username/password directly.

ParametersJSON Schema

Name	Required	Description
`max`	No	Maximum number of results to return (default: 50)
`start`	No	Start position in result set (default: 1)
`xquery`	Yes	The XQuery expression to execute
`endpoint`	No	eXist-db base URL (overrides EXISTDB_ENDPOINT env var)
`password`	No	eXist-db password (overrides EXISTDB_PASSWORD env var)
`show_raw`	No	Include the raw XML REST API response (default: false)
`username`	No	eXist-db username (overrides EXISTDB_USER env var)
`collection`	No	Collection context path (default: '/')

TDQS

B3.2/5.0

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.

existdb_get_documentC

Retrieves the XML content of a document stored in eXist-db.

ParametersJSON Schema

Name	Required	Description
`path`	Yes	Full document path, e.g. '/db/myapp/data/record.xml'
`endpoint`	No
`password`	No
`username`	No

TDQS

C2.8/5.0

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.

existdb_get_xquery_snippetA

Returns a ready-to-use XQuery code snippet for a common eXist-db programming pattern. Available topics: store-document, fulltext-search, restxq, http-client, security, transform-xslt, collection-query.

ParametersJSON Schema

Name	Required	Description	Default
`topic`	Yes	Snippet topic, e.g. 'store-document', 'fulltext-search', 'restxq', 'http-client', 'security', 'transform-xslt', 'collection-query'

TDQS

A3.8/5.0

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.

existdb_list_collectionB

Lists the contents of an eXist-db collection: sub-collections and XML documents with metadata (size, permissions, modification date).

ParametersJSON Schema

Name	Required	Description
`path`	Yes	Collection path, e.g. '/db' or '/db/myapp/data'
`endpoint`	No
`password`	No
`username`	No

TDQS

B3.3/5.0

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.

existdb_list_namespace_functionsA

Lists all documented functions in a given eXist-db / XQuery namespace. Accepts a namespace URI or a conventional prefix (e.g. 'xmldb', 'ft', 'util', 'sm', 'fn').

ParametersJSON Schema

Name	Required	Description	Default
`namespace`	Yes	Namespace URI or prefix, e.g. 'xmldb', 'ft', 'http://exist-db.org/xquery/lucene'

TDQS

A4/5.0

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.

existdb_list_namespacesA

Returns a summary table of all available namespaces in the documentation cache, including their conventional prefix and the number of documented functions.

ParametersJSON Schema

Name	Required	Description	Default
`filter`	No	Filter by namespace category: 'w3c' (XPath/XQuery standard), 'exist' (eXist-db extensions), 'expath' (EXPath/EXQuery), 'appmodule' (application-level modules)

TDQS

A3.6/5.0

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.

existdb_lookup_functionA

Look up the documentation for one or more eXist-db / XQuery functions by name. Returns the full signature, parameter descriptions, return type, and usage notes. Accepts a local name (e.g. 'store'), a prefixed name (e.g. 'xmldb:store'), or a partial match.

ParametersJSON Schema

Name	Required	Description	Default
`name`	Yes	Function name to look up, e.g. 'store', 'xmldb:store', or 'ft:query'
`namespace`	No	Optional namespace URI or prefix to restrict the search, e.g. 'xmldb' or 'http://exist-db.org/xquery/xmldb'

TDQS

A4.4/5.0

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.

existdb_search_functionsA

Full-text search across all eXist-db / XQuery function names and descriptions. Useful for discovering functions when you know what you want to do but not the exact name.

ParametersJSON Schema

Name	Required	Description	Default
`limit`	No	Maximum number of results to return (default: 15)
`keyword`	Yes	Keyword to search for, e.g. 'index', 'collection', 'transform', 'schedule'

TDQS

A4.2/5.0

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.

existdb_store_documentA

Stores (creates or replaces) an XML document in an eXist-db collection via PUT.

ParametersJSON Schema

Name	Required	Description
`content`	Yes	Valid XML string content of the document
`endpoint`	No
`filename`	Yes	Document filename, e.g. 'record.xml'
`password`	No
`username`	No
`collection`	Yes	Target collection path, e.g. '/db/myapp/data'

TDQS

A3.5/5.0

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.

existdb_validate_xqueryA

Validates the syntax of an XQuery expression against a live eXist-db instance without executing it. Returns syntax errors with line/column information if present.

ParametersJSON Schema

Name	Required	Description
`xquery`	Yes	The XQuery expression to validate
`endpoint`	No
`password`	No
`username`	No

TDQS

A4/5.0

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.

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.

12 tool updatesv1.0.0Aug 9, 2026
- First observedexistdb_create_collection
- First observedexistdb_delete_resource
- First observedexistdb_execute_query
- First observedexistdb_get_document
- First observedexistdb_get_xquery_snippet
- First observedexistdb_list_collection
- First observedexistdb_list_namespace_functions
- First observedexistdb_list_namespaces
- First observedexistdb_lookup_function
- First observedexistdb_search_functions
- First observedexistdb_store_document
- First observedexistdb_validate_xquery

Install Server

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A3.8/5.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.

Maintenance

ActivityInactive

ResponsivenessNo issues

Resources

GitHub Repository

Need Help?

Related Servers

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

Remote Desktop CommanderOAuth
app.desktopcommander
Hosted MCP server connecting claude.ai, ChatGPT and other AI apps to your own computer
Shell Access OS Automation
214
XDaLa Workflow Builder B
io.github.xgr-network
Remote MCP server for XDaLa workflow preparation on XGR.Network.
Developer Tools App Automation
952
mcp
dev.augments
Augments MCP Server - A comprehensive framework documentation provider for Claude Code
Developer Tools Documentation Access
2128
Inistate MCPOAuth
io.github.Inistate
MCP server for the Inistate platform: module discovery, entry management, and activity submission.
Content Management Systems Project Management
21

Related MCP Servers

Co-Reading MCP
Note Taking Knowledge & Memory File Systems
idleprocesscc
A
license
B
quality
C
maintenance
A local MCP server that gives Claude a durable reading room for EPUB and plain text books, enabling chunk-by-chunk navigation, annotations, progress tracking, and shared margin cards.
Updated 9 days ago (2026-08-28 07:50 UTC)
26
111
MIT
Local Development MCP Server
Developer Tools File Systems Knowledge & Memory
lreb
A
license
Not graded
quality
C
maintenance
A local MCP server for Claude Desktop with persistent task management, file operations, document generation, and PDF indexing.
Updated 6 months ago (2026-03-19 20:49 UTC)
225
1
MIT
RLM Knowledge Base
RAG Systems Search File Systems
cgaeking
A
license
Not graded
quality
A
maintenance
An MCP server that enables Claude Desktop to search and read local documents via full-text and fuzzy search, providing direct access to indexed files without chunking.
Updated 2 months ago (2026-06-29 12:06 UTC)
MIT
fontem-mcp-serverofficial
Design Tools
fontem-eu
A
license
Not graded
quality
B
maintenance
A Model Context Protocol server that surfaces Fontem entities and queries to Claude via standard MCP tools.
Updated 2 days ago (2026-09-04 14:01 UTC)
Apache 2.0

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

existdb-mcp

What you get

Who is this for?

Table of contents

Quick start

1. Clone and install

2. Build the documentation cache

3. Build the TypeScript

4. Try it

Configuring Claude

Claude Code

Claude Desktop

Environment variables

Available tools

Documentation (offline — no eXist-db needed)

Query execution (requires a live eXist-db)

Collection management (requires a live eXist-db)

Example prompts

Working with TEI corpora

Ecosystem

Testing

Troubleshooting

Regenerating the documentation cache

Project structure

Contributing

License

Available Tools

Tool Schema Changelog

Maintenance

Resources

Looking for Admin?

Related MCP Connectors

Related MCP Servers

fontem-mcp-serverofficial

Latest Blog Posts

MCP directory API