Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@canton-mcp Show me the CC price trend 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.
An MCP server for the Noves Canton API — balances, rewards, classified transactions, CC prices, identity, and the network directory, queryable from Claude Code, Claude Desktop, Cursor, or any MCP-capable agent.
You: How has the CC price moved over the last 7 days? Chart it.
AI: → get_price(startDate, endDate, interval: "daily")
CC closed at $0.1462 today, up 4.2% on the week (low $0.1402, high $0.1521).
[renders an interactive price chart]Get your free API key at https://app.noves.fi/register/free.
Download canton-mcp.mcpb from the
latest release,
double-click it (or drag into Claude Desktop), and paste your API key in the
settings form that appears. The key is stored in your OS keychain. Done.
npx -y @noves/canton-mcp init # one-time: prompts for your key, validates it, saves it
claude mcp add canton -- npx -y @noves/canton-mcpOr in one line, passing the key explicitly:
claude mcp add canton --env NOVES_API_KEY=<your-key> -- npx -y @noves/canton-mcpAfter npx -y @noves/canton-mcp init, no env var is needed:
{
"mcpServers": {
"canton": {
"command": "npx",
"args": ["-y", "@noves/canton-mcp"]
}
}
}(Or skip init and add "env": { "NOVES_API_KEY": "<your-key>" }.)
Key resolution order: NOVES_API_KEY env var → --api-key flag →
~/.config/canton-mcp/config.json. The key is sent only to
api.canton.noves.fi and never logged.
Related MCP server: TON BLOCKCHAIN MCP
Every tool that takes a party accepts an ANS name, a display name, or a
raw party ID (name::hash) — resolution is automatic, and ambiguous names
return a candidate list to choose from.
Examples:
"Who are the super validators on Canton?" → search_directory(orgType: "sv")
"What's Noves' current CC balance?" → get_balance(party: "noves.unverified.cns")
"Chart Noves' balance over the last 30 days." → get_balance_history(party, startDate, endDate)
"Show recent traffic purchases for this validator." → get_transactions(party, txType: "buyTraffic")
Tool | What it answers |
| "Who is this party?" — canonical party ID, org type, balance, ANS names |
| "Who are the super validators?" — browse/filter the network directory |
| "What's this party's balance?" — current or at any point in time ( |
| "Chart its balance over last month" — daily end-of-day snapshots |
| "What did it earn?" — summary metrics, per-day totals, or individual payouts |
| "Show its recent traffic purchases" — classified history (transfer, buyTraffic, …) |
| "How active is it?" — counts, volumes, unique counterparties |
| "CC price trend this month?" — spot, historical spot, hourly/daily OHLC |
| Full classified payload of one update by ID |
See examples/PROMPTS.md for questions to try.
Read-only. The server only reads data; it can't change anything on the network or in your account.
Date inputs accept ISO dates (2026-06-01), ISO datetimes, or unix timestamps.
Daily rewards are fetched in ≤30-day windows upstream; the server merges up to 90 days per call.
List outputs are capped (default 25 rows) with hasMore hints to keep agent context lean.
get_transactions returns 25 rows by default and accepts limit up to 100; use
includeCount for the total count in a date window, and get_transaction for one full update.
Chains/txTypes (1h), directory & identity lookups (5m), and spot price (60s) are cached in-process, keeping typical agent sessions comfortably inside the free tier.
MIT © Noves Inc.
Get a Canton party's CC balance (total, locked, unlocked) with USD values — current, or at any point in time via the optional date. "What was X's balance on January 1?" → date: "2026-01-01".
| Name | Required | Description | Default |
|---|---|---|---|
| date | No | Point-in-time balance: ISO date (2026-01-01), ISO datetime, or unix timestamp. Omit for current. | |
| chain | No | Chain to query. Defaults to "canton" (currently the only supported chain). | canton |
| party | Yes | The party to query — accepts an ANS name (e.g. noves.unverified.cns), a display name (e.g. Cumberland), or a raw Canton party ID (name::hash). |
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.
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.
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.
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.
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.
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.
Get a Canton party's daily CC balance series. Each row is the end-of-day (UTC) snapshot for that date. Defaults to the last 30 days when no range is given.
| Name | Required | Description | Default |
|---|---|---|---|
| chain | No | Chain to query. Defaults to "canton" (currently the only supported chain). | canton |
| party | Yes | The party to query — accepts an ANS name (e.g. noves.unverified.cns), a display name (e.g. Cumberland), or a raw Canton party ID (name::hash). | |
| endDate | No | Range end (inclusive): ISO date, ISO datetime, or unix timestamp. | |
| startDate | No | Range start: ISO date, ISO datetime, or unix timestamp. |
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.
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.
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.
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.
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.
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.
Get the Canton Coin (CC) USD price. No arguments → current spot price. timestamp → historical spot at that moment. startDate+endDate → OHLC series (interval: "hourly" or "daily", default daily). Good for "what's the CC price trend over the past month?".
| Name | Required | Description | Default |
|---|---|---|---|
| chain | No | Chain to query. Defaults to "canton" (currently the only supported chain). | canton |
| endDate | No | History range end. | |
| interval | No | OHLC bucket size for range queries. | daily |
| startDate | No | History range start (use with endDate). | |
| timestamp | No | Historical spot price at this moment: ISO date, ISO datetime, or unix timestamp. |
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.
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.
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.
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.
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.
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.
Get a Canton party's mining/validator rewards. Three granularities: "summary" (default) — current earnings metrics (latest round, 1h avg, 24h avg, incl. post-traffic-cost CC/USD); "daily" — per-day totals over a date range (max 90 days per call); "transfers" — individual reward transfers. Optionally filter by rewardType.
| Name | Required | Description | Default |
|---|---|---|---|
| chain | No | Chain to query. Defaults to "canton" (currently the only supported chain). | canton |
| limit | No | Max transfer rows when granularity is transfers (default 25, max 100). | |
| party | Yes | The party to query — accepts an ANS name (e.g. noves.unverified.cns), a display name (e.g. Cumberland), or a raw Canton party ID (name::hash). | |
| endDate | No | Range end (inclusive): ISO date, ISO datetime, or unix timestamp. | |
| startDate | No | Range start: ISO date, ISO datetime, or unix timestamp. | |
| rewardType | No | Filter to one reward type (transfers granularity only). | |
| granularity | No | summary = current earnings metrics; daily = per-day totals; transfers = individual reward payouts. | summary |
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.
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.
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.
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.
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.
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.
Get the full classified detail of a single Canton update (transaction) by its update ID, including the complete payload: classification, all parties and roles, transfers, values, and raw transaction data. Use after get_transactions when you need everything about one update.
| Name | Required | Description | Default |
|---|---|---|---|
| chain | No | Chain to query. Defaults to "canton" (currently the only supported chain). | canton |
| updateId | Yes | The update ID (from get_transactions rows). |
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.
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.
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.
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.
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.
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.
Get a Canton party's transaction history, classified into human-readable types (transfer, mergeSplit, validatorRewards, appRewards, svRewards, buyTraffic, issueCoupon, redeemCoupon, paySubscription, validatorLicenseActivityReport, …). Returns compact rows (id, time, type, roles, transfer summary) sorted newest-first. Use get_transaction for the full payload of one update. Set includeCount: true to also get the total update count for the window.
| Name | Required | Description | Default |
|---|---|---|---|
| chain | No | Chain to query. Defaults to "canton" (currently the only supported chain). | canton |
| limit | No | Max rows (default 25, max 100). | |
| party | Yes | The party to query — accepts an ANS name (e.g. noves.unverified.cns), a display name (e.g. Cumberland), or a raw Canton party ID (name::hash). | |
| txType | No | Filter to one classification type (e.g. transfer, buyTraffic, validatorRewards). Filtered client-side over recent pages. | |
| endDate | No | Range end (inclusive): ISO date, ISO datetime, or unix timestamp. | |
| startDate | No | Range start: ISO date, ISO datetime, or unix timestamp. | |
| includeCount | No | Also return the total number of updates in the window (one extra API call). |
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.
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.
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.
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.
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.
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.
Get aggregate CC transfer statistics for a Canton party: total/sent/received counts, volumes, and unique counterparty count — optionally over a date range.
| Name | Required | Description | Default |
|---|---|---|---|
| chain | No | Chain to query. Defaults to "canton" (currently the only supported chain). | canton |
| party | Yes | The party to query — accepts an ANS name (e.g. noves.unverified.cns), a display name (e.g. Cumberland), or a raw Canton party ID (name::hash). | |
| endDate | No | Range end (inclusive): ISO date, ISO datetime, or unix timestamp. | |
| startDate | No | Range start: ISO date, ISO datetime, or unix timestamp. |
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.
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.
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.
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.
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.
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.
Resolve a human-friendly query (ANS name, display name, or raw party ID) to a canonical Canton party. Returns the party ID, display name, org type (validator / app / sv / unknown), current CC balance, ANS names, and update count. If the query is ambiguous, returns a candidate list to choose from. Use this first whenever the user refers to a party by name.
| Name | Required | Description | Default |
|---|---|---|---|
| chain | No | Chain to query. Defaults to "canton" (currently the only supported chain). | canton |
| query | Yes | ANS name (e.g. noves.unverified.cns), display name fragment (e.g. Cumberland), or raw party ID (name::hash). |
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.
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.
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.
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.
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.
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.
Browse or search the Canton network directory of known parties (validators, apps, super validators). Filter by orgType and/or a free-text query. Returns party ID, display name, org type, and current CC balance. Ask "who are the super validators?" → orgType: "sv".
| Name | Required | Description | Default |
|---|---|---|---|
| chain | No | Chain to query. Defaults to "canton" (currently the only supported chain). | canton |
| limit | No | Max results to return (default 25, max 100). | |
| query | No | Free-text search over names. | |
| orgType | No | Filter by organization type. sv = super validator. |
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.
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.
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.
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.
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.
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.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
v0.2.3get_balanceget_balance_historyget_priceget_rewardsget_transactionget_transactionsget_transfer_statsresolve_partysearch_directoryScored across 9 tools
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.
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.
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.
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.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
MCP server connecting AI agents to non-custodial staking data across 130+ networks.
MCP server for AI agents to plan, verify, and deploy Cloudflare-native apps.
MCP server for building and testing AI agents with multi-model experimentation and insights.
MCP server for AI agents to discover campaigns by humans and donate USDC directly on Base.
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