canton-mcp

Server Quality Checklist

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

Latest release: v0.2.3
Disambiguation5/5
Each tool has a clearly distinct purpose: party resolution, directory search, balances (current and history), rewards, transactions (list and detail), transfer statistics, and price. No overlap or ambiguity.
Naming Consistency5/5
All tool names follow a consistent verb_noun pattern in snake_case (e.g., resolve_party, get_balance, get_transactions), making them predictable and easy to understand.
Tool Count5/5
With 9 tools, the set is well-scoped for a Canton network exploration server. Each tool addresses a specific query need without unnecessary bloat or missing essentials.
Completeness5/5
The tool set comprehensively covers the domain of party information, balances, rewards, transactions, and prices. No obvious gaps for the intended purpose of network monitoring and data retrieval.
Average 4.2/5 across 9 of 9 tools scored. Lowest: 3.5/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 14 commits in the last 12 weeks
- Last stable release on June 5, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
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

Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses default range (30 days) and data granularity, but lacks details on safety (read-only), authentication needs, or rate limits. Without annotations, the description carries the burden and is adequate but not comprehensive.
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 extremely concise with two sentences, front-loading the core purpose and providing key operational details. No superfluous information.
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 omits details about the response format (e.g., fields returned), pagination, or error handling. For a tool without output schema, this leaves gaps for the agent. However, the core functionality is conveyed.
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 provides 100% coverage with descriptions for all 4 parameters. The description adds context about default range and daily nature, but does not significantly enhance understanding beyond the schema. Baseline score 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 tool retrieves a Canton party's daily CC balance series, with specifics on granularity (daily, end-of-day UTC). It effectively distinguishes from siblings like get_balance (current) and get_transactions.
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 explicit guidance on when to use this tool versus alternatives. The description implies usage for historical daily balances but does not mention when not to use or provide comparative context with siblings.
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 provided, so the description carries the transparency burden. It discloses that the tool returns balance components with USD values, but lacks details on authentication, rate limits, or error handling. The read-only nature is implied but not stated.
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 plus a clear usage example, front-loading the core purpose. Every word adds value, with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description adequately explains the return values (balance components with USD values). It covers the three parameters and their purposes. However, it could elaborate on the exact response structure for better completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, but the description adds significant meaning: it explains the optional date usage with a natural language example and clarifies that the party parameter accepts ANS names, display names, or raw IDs, going beyond schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves a Canton party's CC balance with specific breakdown (total, locked, unlocked) and USD values, and distinguishes it from siblings like 'get_balance_history' by focusing on current or point-in-time balance.
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 provides an example of using the optional date parameter for historical queries, but does not explicitly guide when to use this tool vs. alternatives (e.g., get_balance_history, get_rewards) or mention prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavior. It correctly indicates a read operation ("Get") and optional date filtering, but could add that it is non-destructive and returns aggregated data without side effects. The behavior is adequately transparent for a statistics tool.
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 conveys all essential information without redundancy or extraneous words. It is front-loaded with the core action and resource.
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?
The description covers what the tool returns and the optional date range. It does not mention output structure or pagination, but for an aggregate stats tool with no output schema, it is reasonably complete. Could specify that it returns a single object with the listed fields.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3. The description adds little beyond restating the optional date range; it does not enhance parameter meaning beyond the schema's own descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves aggregate CC transfer statistics for a Canton party, specifying the exact metrics (total/sent/received counts, volumes, unique counterparty count) and optional date range. It distinguishes from sibling tools like get_transactions, which lists individual transfers.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for aggregate statistics but does not explicitly state when to use this tool versus alternatives (e.g., get_transactions for individual records). No guidance on prerequisites or scenarios to avoid.
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 alone must convey behavioral traits. It correctly implies a read-only operation (browse/search) and specifies the return fields. However, it does not mention whether the operation has side effects, requires authentication, or has rate limits. For a read-only tool, this is adequate but not comprehensive.
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 very concise: two sentences plus an example. It front-loads the main action ('Browse or search...') and immediately follows with supported filters and output. Every sentence adds value, and the example is well-placed. No unnecessary words or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of output schema and annotations, the description covers the essential aspects: what the tool does, its filters, and the returned fields. It also provides a concrete example. It could mention that results are limited by the 'limit' parameter and whether pagination is supported, but the schema covers the limit parameter. Overall, it is complete enough for typical usage.
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?
Input schema coverage is 100%, so the schema already documents all parameters. The description adds a usage example that clarifies the interaction between orgType and query, and it explains the 'sv' enum value. While helpful, this does not significantly exceed the baseline of 3, as the schema's descriptions are already clear.
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's function: browsing or searching the Canton network directory of known parties. It lists filter options (orgType and free-text query) and the returned fields. This distinguishes it from sibling tools like resolve_party, which resolves specific parties, and get_balance, which queries balances. The example usage further clarifies purpose.
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 implicitly guides usage by describing filters and providing an example query for 'who are the super validators?'. While it doesn't explicitly state when to use this tool over alternatives, the context and example offer sufficient guidance for typical use cases. A more explicit 'use this when you need to find or list parties in the directory' would solidify the score.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses key behaviors: three granularities, default summary, date range limit of 90 days for daily, optional rewardType filter, and default limit for transfers. It does not mention error conditions, permissions, or rate limits, but the provided detail is substantial.
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 brief yet comprehensive, using a single well-structured sentence with semicolons to separate granularities. It front-loads the main purpose and immediately provides key details without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description covers the return structure for each granularity in reasonable detail. It explains summary returns, daily totals (with range limit), and transfers (with limit). Missing aspects like error handling or required permissions, but overall sufficient for an agent to understand what to expect.
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 description coverage is 100%, giving a baseline of 3. The description adds extra semantics: it clarifies what each granularity returns (e.g., 'current earnings metrics (latest round, 1h avg, 24h avg, incl. post-traffic-cost CC/USD)') and mentions the 90-day limit for daily, which is absent from the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves a Canton party's mining/validator rewards and then breaks down three granularities (summary, daily, transfers) with specific details, making it distinct from sibling tools like get_balance or get_transactions.
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?
While the description explains the three granularities and their use cases, it does not provide guidance on when to choose this tool over siblings (e.g., get_transactions for transaction history) nor specify when not to use it. The context is clear but lacks exclusionary or comparative advice.
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?
Discloses key behaviors: returns compact rows sorted newest-first, client-side filtering for txType over recent pages, and extra API call for includeCount. As a read-only query, no annotations are provided, but the description adequately implies safety without contradictions.
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 that front-load the main purpose and return format, then offer guidance on alternatives and optional parameter. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Fully explains return format (compact rows with fields), sorting, and the includeCount option. Without an output schema, this is sufficient. Could mention default date ranges or pagination, but not necessary for typical use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema covers 100% of parameters with descriptions. The description adds minor context (e.g., classification types, client-side filtering note), but does not significantly enhance understanding beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses specific verbs ('Get a Canton party's transaction history') and resources, and clearly distinguishes from sibling tool 'get_transaction' by stating 'Use get_transaction for the full payload of one update.'
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?
Provides clear context on when to use this tool vs alternatives by referencing 'get_transaction' for full payload. Also explains optional parameters like includeCount and filtering by txType, but does not explicitly state when not to use this tool.
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 the behavioral differences between parameter combinations (current vs historical spot vs OHLC series) and the default interval. However, it does not mention any rate limits, authentication requirements, or potential side effects, which are minor omissions for a simple read-only price tool.
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 extremely concise: two sentences, front-loaded with the tool's purpose, and each sentence serves a distinct function (purpose + parameter behavior + usage example). No redundancy or filler.
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 tool with 5 parameters and no output schema, the description provides enough context for common use cases. It explains the main modes but does not describe the return format (e.g., what OHLC data looks like). This is a minor gap, but overall it is sufficient for an agent to use the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Although the input schema provides 100% coverage with descriptions for each parameter, the description adds significant semantic grouping by explaining how parameters work together (e.g., 'startDate+endDate → OHLC series'). It also clarifies the default interval ('default daily') and gives an example usage, going 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 verb 'Get' and specific resource 'Canton Coin (CC) USD price'. It distinguishes from sibling tools like get_balance or get_rewards, which deal with different financial data. The mention of 'USD price' and different query modes makes the 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 provides three explicit usage patterns: no arguments for current price, timestamp for historical spot, and startDate+endDate for OHLC series with interval options. It also gives an example question ('what's the CC price trend over the past month?'), effectively guiding the agent. No explicit when-not-to-use or alternatives to sibling tools, but the context is clear enough.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Despite no annotations, the description discloses what the tool returns (complete payload, parties, roles, transfers, values, raw data) and implies read-only behavior through the 'get' verb. It does not explicitly state side effects or permissions, but given the tool's nature, this is sufficient.
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 with no wasted words. The first sentence defines the function, the second provides usage context. Perfectly front-loaded and efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given two simple parameters, no output schema, and no annotations, the description covers what the tool does and what it returns in sufficient detail for an agent to use it correctly.
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 descriptions cover both parameters (100% coverage). The description adds value by linking updateId to get_transactions, clarifying its source, and reinforcing the purpose of the chain parameter with the default note.
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 (Get full classified detail), the resource (single Canton update), and the method (by updateId). It also distinguishes from sibling tool get_transactions by specifying it is for detailed retrieval after getting a list.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly instructs 'Use after get_transactions when you need everything about one update,' providing clear when-to-use context and a prerequisite (updateId from get_transactions).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It discloses that ambiguous queries return a candidate list and lists the return fields (party ID, display name, org type, CC balance, ANS names, update count). It does not mention rate limits or permissions, but these are not critical for a read-only query.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the main purpose, and every sentence adds value. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description adequately explains the return values. It covers usage, input types, behavior on ambiguity, and return fields. For a simple tool with 2 parameters, this is complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with descriptions for both parameters. The description adds value by explaining the query parameter can be an ANS name, display name fragment, or raw party ID, and the chain parameter defaults to 'canton' with a note on current support.
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 resolves a query to a canonical Canton party, listing supported input types and output fields. It differentiates from siblings like search_directory by specifying the use case of resolving party references.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly advises 'Use this first whenever the user refers to a party by name,' providing a clear when-to-use directive. It also implies when not to use (e.g., when transactions are needed), guiding selection among siblings.
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:

[![canton-mcp MCP server](https://glama.ai/mcp/servers/Noves-Inc/canton-mcp/badges/card.svg)](https://glama.ai/mcp/servers/Noves-Inc/canton-mcp)

Score Badge

Copy to your README.md:

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

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