Skip to main content
Glama

canton-ccpedia

by io.github.UnityNodes

list_governance_votes

Read-onlyIdempotent

List Canton Network on-chain DSO governance vote requests and their outcomes, from the ledger itself. Covers Featured App rights being granted or revoked, Super Validator reward-weight changes, SV offboarding, and AmuletRules/DsoRules config changes. CCPEDIA-unique: no other public source exposes this joined to the CIP corpus. Use for 'what has the DSO decided recently', 'which apps got Featured App status', 'what got rejected'. For one CIP's fate use get_cip_vote_outcome; for one Super Validator's record use list_votes_by_sv. Canton ecosystem only.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
limitNoMax rows (default 20).
actionNoFilter by action, e.g. "SRARC_GrantFeaturedAppRight", "SRARC_RevokeFeaturedAppRight", "SRARC_UpdateSvRewardWeight", "SRARC_OffboardSv".
offsetNoSkip this many before returning, for paging past the limit. The response states the full count and echoes the offset used.
statusNo"open" for votes still in flight, "closed" for decided ones. Omit for both; there is no "all" value.
outcomeNoFilter by outcome. Omit for all outcomes; there is no "all" value.

Schema Changelog

Changes observed during successful MCP inspections. Dates show when Glama detected each change.

  1. Changed1 schema field changed
    • addedInput schema / properties / offset
      Added value: +{
+  "default": 0,
+  "description": "Skip this many before returning, for paging past the limit. The response states the full count and echoes the offset used.",
+  "maximum": 9007199254740991,
+  "minimum": 0,
+  "type": "integer"
+}
  2. Changed4 schema fields changed
    • changedInput schema / properties / outcome / description
      Previous value: -"Filter by outcome: \"VRO_Accepted\", \"VRO_Rejected\", \"VRO_Expired\"."New value: +"Filter by outcome. Omit for all outcomes; there is no \"all\" value."
    • addedInput schema / properties / outcome / enum
      Added value: +[
+  "VRO_Accepted",
+  "VRO_Rejected",
+  "VRO_Expired"
+]
    • changedInput schema / properties / status / description
      Previous value: -"\"open\" for votes still in flight, \"closed\" for decided ones."New value: +"\"open\" for votes still in flight, \"closed\" for decided ones. Omit for both; there is no \"all\" value."
    • addedInput schema / properties / status / enum
      Added value: +[
+  "open",
+  "closed"
+]
  3. First observed

TDQS

A4.5/5.0
Behavior4/5

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false. The description adds valuable context about the data source ('from the ledger itself') and unique value ('no other public source exposes this joined to the CIP corpus'), which 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.

Conciseness5/5

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

The description is four sentences, front-loaded with the core purpose, then scope, use cases, and alternatives. Every sentence serves a distinct purpose with no filler or repetition.

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?

For a read-only list tool with rich annotations and complete schema coverage, the description provides essential context on scope, use cases, and alternative tools. The absence of an output schema is mitigated by the schema's parameter descriptions mentioning response behavior (e.g., 'The response states the full count and echoes the offset used').

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The schema provides 100% coverage with clear descriptions for all 5 parameters, including enums and examples. The description reinforces the meaning of the 'action' filter by listing covered actions, but adds no new parameter-level detail beyond what the schema already documents.

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 'List Canton Network on-chain DSO governance vote requests and their outcomes' with a specific verb and resource. It distinguishes from siblings by explicitly naming get_cip_vote_outcome and list_votes_by_sv, and notes 'Canton ecosystem only' to set boundaries.

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 provides explicit use cases: 'Use for "what has the DSO decided recently", "which apps got Featured App status", "what got rejected"' and exclusions: 'For one CIP's fate use get_cip_vote_outcome; for one Super Validator's record use list_votes_by_sv.' This clearly states when and when not to use the tool.

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

All canton-ccpedia toolsInspect
Try in Browser
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A3.7/5.0
Disambiguation2/5

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.

Naming Consistency5/5

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.

Tool Count1/5

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.

Completeness5/5

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.

Resources