How do I use Daml/Canton Docs 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., "@Daml/Canton Docs MCP search Daml docs for contract keys" 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.

Daml/Canton Docs MCP

by stevennevins

Overview Schema Related Servers Score Discussions

Python

Local

Daml/Canton Docs MCP

This repository builds and serves local MCP-searchable documentation indexes for the Daml, Canton, Canton Network, DPM, CN Quickstart, and Splice documentation sources.

The installed command is docs-mcp. It can:

sync configured documentation sources into .docs/
build SQLite FTS5 indexes for local search
query an index from the command line
serve an index over stdio or streamable HTTP as an MCP server

The primary docset is daml, which combines:

daml-sdk from digital-asset/daml
canton from digital-asset/canton
dpm from digital-asset/dpm
cn-quickstart from digital-asset/cn-quickstart
canton-network from docs.canton.network
splice from canton-network/splice

Setup

Requirements: Python 3.10+, uv, and Git.

uv sync
uv run docs-mcp list

Related MCP server: Atlas

Build or refresh indexes

Build the combined Daml/Canton index:

uv run docs-mcp update daml \
  --export-dir .docs/daml \
  --db-path .docs/daml/docs_index.db

Build an individual source index by replacing daml with a configured docset, for example canton, daml-sdk, canton-network, or splice.

Generated sources, caches, and indexes live under .docs/ and .cache/ and are ignored by Git.

Use through mcporter

This is the expected usage path for agents: register the daml docs server with mcporter, then call the generated tools on demand instead of loading the MCP server directly into every session.

Add a server entry to ~/.mcporter/mcporter.json or to a project-local config/mcporter.json. Use absolute paths because mcporter may start the server outside this checkout.

{
  "mcpServers": {
    "daml": {
      "command": "/absolute/path/to/uv",
      "args": [
        "run",
        "--directory",
        "/absolute/path/to/daml-docs-mcp",
        "docs-mcp",
        "--root",
        "/absolute/path/to/daml-docs-mcp",
        "serve",
        "daml",
        "--export-dir",
        "/absolute/path/to/daml-docs-mcp/.docs/daml",
        "--db-path",
        "/absolute/path/to/daml-docs-mcp/.docs/daml/docs_index.db"
      ]
    }
  }
}

Verify the registration and call the search tool:

mcporter list daml --schema
mcporter call daml.search_daml --args '{"query":"contract keys","scope":"chunks","limit":8}'

Refresh the index through the same registered server:

mcporter call daml.refresh_daml_index

Query locally

uv run docs-mcp query daml \
  --db-path .docs/daml/docs_index.db \
  --scope chunks \
  --limit 8 \
  "contract keys"

Combined daml results prefix categories with their member docset, such as canton:sdk, so callers can tell which source matched.

Serve as MCP

Serve over stdio for an MCP client:

uv run docs-mcp serve daml \
  --db-path /absolute/path/to/daml-docs-mcp/.docs/daml/docs_index.db

Serve over streamable HTTP:

uv run docs-mcp serve daml \
  --db-path .docs/daml/docs_index.db \
  --transport streamable-http \
  --port 8765

MCP client configs should use absolute paths for this repository and for --db-path, because clients may start the server from a different working directory.

Configurations

Docsets are configured in configs/*.json. configs/daml.json is the combined index; the other Daml/Canton-related files define the source repositories, website source, public URL mapping, and file suffixes copied into the export.

configs/hermes.json, configs/claude_code.json, and configs/template.json remain from the upstream docs MCP template and are not part of the Daml/Canton package workflow.

Development checks

Run these before changing CLI, export, indexing, or MCP behavior:

uv run ruff format --check .
uv run ruff check .
uv run mypy
uv run python -m unittest discover -s tests -v

Project map

docs_mcp/cli.py: docs-mcp command entry point.
scripts/sync_docset.py: syncs sources and rebuilds exports/indexes.
scripts/export_docs.py: copies docs and writes sitemap/export files.
scripts/build_fts_index.py: builds SQLite FTS5 indexes.
scripts/query_fts.py: queries indexes from the CLI.
scripts/docs_mcp_server.py: serves MCP tools.
configs/: docset configuration files.
tests/: regression tests.

License

MIT. See LICENSE.

Available Tools

6 tools

get_daml_chunkD

ParametersJSON Schema

Name	Required	Description	Default
`chunk_index`	Yes
`export_path`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

D1/5.0

Behavior1/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Tool has no description.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness1/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Tool has no description.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness1/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Tool has no description.

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?

Tool has no description.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose1/5

Does the description clearly state what the tool does and how it differs from similar tools?

Tool has no description.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines1/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Tool has no description.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

get_daml_docD

ParametersJSON Schema

Name	Required	Description	Default
`url`	No
`title`	No
`export_path`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

D1/5.0

Behavior1/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Tool has no description.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness1/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Tool has no description.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness1/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Tool has no description.

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?

Tool has no description.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose1/5

Does the description clearly state what the tool does and how it differs from similar tools?

Tool has no description.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines1/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Tool has no description.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

get_daml_index_infoD

ParametersJSON Schema

Name	Required	Description	Default
No parameters

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

D1/5.0

Behavior1/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Tool has no description.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness1/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Tool has no description.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness1/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Tool has no description.

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?

Tool has no description.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose1/5

Does the description clearly state what the tool does and how it differs from similar tools?

Tool has no description.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines1/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Tool has no description.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

list_daml_pagesD

ParametersJSON Schema

Name	Required	Description	Default
`limit`	No
`category`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

D1/5.0

Behavior1/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Tool has no description.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness1/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Tool has no description.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness1/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Tool has no description.

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?

Tool has no description.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose1/5

Does the description clearly state what the tool does and how it differs from similar tools?

Tool has no description.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines1/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Tool has no description.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

refresh_daml_indexD

ParametersJSON Schema

Name	Required	Description	Default
No parameters

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

D1/5.0

Behavior1/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Tool has no description.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness1/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Tool has no description.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness1/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Tool has no description.

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?

Tool has no description.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose1/5

Does the description clearly state what the tool does and how it differs from similar tools?

Tool has no description.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines1/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Tool has no description.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

search_damlD

ParametersJSON Schema

Name	Required	Default
`limit`	No
`query`	Yes
`scope`	No	chunks
`rerank`	No
`category`	No
`per_page_cap`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

D1/5.0

Behavior1/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Tool has no description.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness1/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Tool has no description.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness1/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Tool has no description.

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?

Tool has no description.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose1/5

Does the description clearly state what the tool does and how it differs from similar tools?

Tool has no description.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines1/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Tool has no description.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Install Server

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

TDQS

C2.1/5.0

Disambiguation4/5

Each tool has a clear primary purpose: search, get a doc, get a chunk, list pages, inspect index, and refresh index. The only potential ambiguity is between get_daml_doc and get_daml_chunk, which could be confused without detailed descriptions, but their names suggest a whole-part relationship.

Naming Consistency5/5

All tool names follow a consistent verb_daml_entity pattern using snake_case (e.g., search_daml, get_daml_doc, refresh_daml_index). The verb is consistently placed first and the suffix 'daml' appears uniformly, making the naming predictable and scannable.

Tool Count5/5

With 6 tools, the server is well-scoped for a documentation retrieval and indexing service. The count covers search, retrieval, list, and index management without unnecessary bloat, making it easy for agents to choose the right tool.

Completeness4/5

The tool surface covers the core documentation workflow: searching, retrieving, listing, and index maintenance. A minor gap is that there is no explicit tool to fetch all chunks for a document at once, but this is likely achievable via list_daml_pages and repeated get_daml_chunk calls.

Maintenance

ActivityStale

ResponsivenessSyncing

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

OrchestKit Docs MCP A
io.github.yonatangross
Read-only MCP server for the OrchestKit docs: full-text search + Markdown fetch. No auth.
Documentation Access Search
23186
trip2g A
io.github.trip2g
Serve a folder of Markdown notes as an MCP server: hybrid search, reading, and sourced answers.
RAG Systems Note Taking Search
11237
forkast-mcp-docs A
io.github.ForkastPredict
MCP server for querying Forkast documentation
Documentation Access Search Developer Tools
42
ctx A
io.github.vanshulgoyal101
Turn a GitHub repo or docs site into agent-ready context: pack it or search it, over MCP.
RAG Systems Search Documentation Access
611

Related MCP Servers

docs-mcp
Documentation Access Search
kage1020
F
license
Not graded
quality
D
maintenance
Indexes documentation sites by base URL and serves keyword search, optional semantic search, and Markdown page retrieval as MCP tools, all from a single SQLite file.
Updated 4 months ago (2026-05-17 13:29 UTC)
Atlas
Documentation Access Search RAG Systems
moxellabs
A
license
Not graded
quality
A
maintenance
Local-first MCP server for querying multi-repo engineering documentation artifacts from a SQLite corpus.
Updated 9 days ago (2026-08-25 01:07 UTC)
11
AGPL 3.0
repodoc MCP server
RAG Systems Documentation Access Vector Databases
ktocdev
F
license
Not graded
quality
C
maintenance
Provides a local MCP server for Claude Code to retrieve relevant documentation slices from a repository's auto-generated reference docs using hybrid search (vector + BM25).
Updated 2 months ago (2026-07-04 21:53 UTC)
okf
aminHZDEV
A
license
Not graded
quality
A
maintenance
Builds a keyword-searchable index from markdown documentation bundles and serves it to LLM agents via MCP, with retrieval logging and reporting for curation.
Updated a month ago (2026-07-19 07:55 UTC)
MIT

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/stevennevins/daml-docs-mcp'

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