cardano_query_committee_stateRetrieve the current constitutional committee state from a Cardano node to inspect members, terms, and governance status.
Query the current constitutional committee state.
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
Changes observed during successful MCP inspections.
v1.0.0Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint=false, so the safety profile is fully covered by structured data. The description adds nothing behavioral beyond that (no indication of what the state snapshot contains, freshness, or whether it can be empty), so it contributes little that the annotations don't.
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?
A single short sentence with the resource front-loaded and no filler. Nothing needs to be trimmed.
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?
There are no parameters and no output schema, and annotations cover the safety profile, but the description never says what 'committee state' comprises (members, term expiry, thresholds), which is exactly the gap the description should fill when no output schema exists. Adequate but thin for a state-query tool.
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 tool takes zero parameters, so per the rubric the baseline is 4. There is nothing for the description to clarify on the parameter side.
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?
Specific verb (Query) plus a precise resource (current constitutional committee state). It implicitly separates itself from siblings like cardano_query_constitution and cardano_query_drep_state by naming the committee rather than the constitution or DREPs, but it does not explicitly contrast with them or with cardano_query_gov_state.
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?
Usage is implied by the name and description — call it to inspect the constitutional committee — but there is no statement of when to prefer it over cardano_query_gov_state or cardano_query_constitution, and no prerequisites or exclusions are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.