List all known deprecated Daml/Canton CLI commands, packages, and tools with their modern replacements. Returns a compact table you can scan, optionally filtered by category (cli, package, tool, api, workflow). Canton/Daml/Splice only. Use this to enumerate or browse; use migrate_lookup for a specific name.
| Name | Required | Description | Default |
|---|---|---|---|
| category | No | Kind of thing deprecated. "all" (default) returns every category. | all |
Changes observed during successful MCP inspections. Dates show when Glama detected each change.
Input schema / properties / category / descriptionAdded value: +"Kind of thing deprecated. \"all\" (default) returns every category."Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover read-only/idempotent safety. The description adds behavioral context by stating the return format ('compact table you can scan'), the optional category filtering, and the scope restriction. This goes beyond the annotations without contradicting them.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is four concise sentences, each serving a distinct purpose: what the tool does, what the output looks like and its optional filtering, scope limitation, and when to choose this tool over migrate_lookup. No unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with one optional parameter and good annotations, the description is complete: it covers the tool's purpose, output format, scope, and usage guidance. No output schema is needed given the clear 'compact table' statement.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema fully documents the single parameter (category) with enum values, default, and description. The description mentions the filter and lists some enum values, but adds no new semantic meaning beyond what the schema already provides, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action (list) and resource (all known deprecated Daml/Canton CLI commands, packages, and tools) and clarifies the output (with their modern replacements). It also distinguishes itself from the sibling migrate_lookup by explicitly framing itself as the tool for enumeration or browsing.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance: 'Use this to enumerate or browse; use migrate_lookup for a specific name.' This names an alternative and defines when to use each. It also notes the scope 'Canton/Daml/Splice only,' which helps the agent decide applicability.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add one secure layer between your agents and this server.
Many tools have overlapping search/retrieval functionality (search, semantic_search, full_context, search_community, search_github_issues, etc.), and the CIP-specific variants (get_cip, get_cip_history, get_cip_votes, get_cip_mentions, get_cip_citations) are numerous and subtly differentiated. Despite cross-references in the descriptions, the boundaries are fine-grained and an agent is likely to misselect among the 8+ search tools or the 8+ CIP tools.
All tool names follow a consistent verb_noun snake_case pattern (get_x, list_x, search_x, find_x). Mixed styles or camelCase are absent, and the verb choice (get, list, search, find, detect, compare) is semantically appropriate to each action, making the naming highly predictable.
With 88 tools, the surface is extremely overgrown for a single server, far exceeding the 25+ 'too many' threshold and approaching the 50+ 'extreme mismatch' category. Even for a comprehensive ecosystem knowledge base, this creates a massive selection burden and makes the tool set unwieldy for agents.
The server covers the full Canton ecosystem: docs, forum, mailing lists, GitHub, CIPs, governance, validators, versions, deprecations, security, and media. There are no glaring gaps in the knowledge domain; every major resource type has retrieval and analysis tools, making the coverage exhaustive with no obvious dead ends.