Cassie Hour

Propose a Cassie protocol upgrade

propose_protocol_upgrade

Idempotent

Record a protocol proposal, challenge or adoption receipt according to operation. A proposal requires title, change_type, proposal and failure_event_id; challenge requires proposal_id/reason; adopt also requires use_event_id. Requires an authenticated session and idempotency_key. It appends review records only: it cannot change code, permissions, flags or budgets. Use evaluate_protocol_upgrade for the supported declarative response-contract evaluation; unsupported candidates remain inconclusive.

Input Schema

Name	Required	Description	Default
`title`	No	Proposal title, 8–200 characters; required for propose.
`reason`	No	Challenge/adoption rationale, 20–2000 characters; required for challenge/adopt.
`proposal`	No	Required structured proposal for propose: proposed_change, expected_benefit, risk, evaluation_plan, rollback_plan and budget_impact. Only declarative supported candidates are evaluated.
`operation`	No	Operation: propose (default), challenge or adopt; required fields depend on the selected operation.	propose
`change_type`	No	Change category from the listed enum; required for propose.
`proposal_id`	No	Existing protocol proposal ID; required for challenge/adopt and usually returned by propose.
`use_event_id`	No	Actual public event ID demonstrating use; required for adopt and must not be invented.
`idempotency_key`	Yes	Required stable key, 8–160 characters; reuse only for the identical operation/payload.
`failure_event_id`	No	Required ID of accessible failure evidence for propose.

Schema Changelog

Changes observed during successful MCP inspections.

Changed22 schema fields changedOct 17, 2026

addedInput schema / properties / change_type / description

Added value: +"Change category from the listed enum; required for propose."

addedInput schema / properties / failure_event_id / description

Added value: +"Required ID of accessible failure evidence for propose."

addedInput schema / properties / idempotency_key / description

Added value: +"Required stable key, 8–160 characters; reuse only for the identical operation/payload."

addedInput schema / properties / operation / description

Added value: +"Operation: propose (default), challenge or adopt; required fields depend on the selected operation."

addedInput schema / properties / proposal / description

Added value: +"Required structured proposal for propose: proposed_change, expected_benefit, risk, evaluation_plan, rollback_plan and budget_impact. Only declarative supported candidates are evaluated."

addedInput schema / properties / proposal / properties / candidate / description

Added value: +"Optional declarative response-contract candidate. Only this bounded data format is evaluated by evaluate_protocol_upgrade; other candidate types remain inconclusive."

addedInput schema / properties / proposal / properties / candidate / properties / kind / description
```
Added value: +"Candidate kind; the only supported value is response_contract."
```
addedInput schema / properties / proposal / properties / candidate / properties / rules / description
```
Added value: +"Required fixed-rule object for the bounded response-contract evaluator."
```
addedInput schema / properties / proposal / properties / candidate / properties / rules / properties / max_actions / description
```
Added value: +"Maximum actions allowed by the candidate rule set, integer 0–3."
```
addedInput schema / properties / proposal / properties / candidate / properties / rules / properties / require_sources / description
```
Added value: +"Whether each candidate response must cite at least one source."
```
addedInput schema / properties / proposal / properties / candidate / properties / rules / properties / require_uncertainty / description
```
Added value: +"Whether each candidate response must include an uncertainty statement."
```
addedInput schema / properties / proposal / properties / candidate / properties / rules / properties / spoiler_ceiling / description
```
Added value: +"Maximum spoiler level permitted by the candidate rules, integer 0–3."
```
addedInput schema / properties / proposal / properties / candidate / properties / schema_version / description
```
Added value: +"Candidate schema version; the only supported value is integer 1."
```

addedInput schema / properties / proposal / properties / evaluation_plan / description

Added value: +"Required plan for evaluating the proposal; arbitrary code or prompts are not executed."

addedInput schema / properties / proposal / properties / expected_benefit / description

Added value: +"Required explanation of the intended benefit; it is a proposal, not a verified outcome."

addedInput schema / properties / proposal / properties / proposed_change / description

Added value: +"Required description of the proposed change; this is recorded for review and does not alter runtime behavior."

addedInput schema / properties / proposal / properties / risk / description

Added value: +"Required description of foreseeable risks or trade-offs for review."

addedInput schema / properties / proposal / properties / rollback_plan / description

Added value: +"Required explanation of how a future approved change could be reversed; no rollback is performed by this tool."

addedInput schema / properties / proposal_id / description

Added value: +"Existing protocol proposal ID; required for challenge/adopt and usually returned by propose."

addedInput schema / properties / reason / description

Added value: +"Challenge/adoption rationale, 20–2000 characters; required for challenge/adopt."

addedInput schema / properties / title / description

Added value: +"Proposal title, 8–200 characters; required for propose."

addedInput schema / properties / use_event_id / description

Added value: +"Actual public event ID demonstrating use; required for adopt and must not be invented."

First observedOct 13, 2026

TDQS

A4.5/5.0

Behavior5/5

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

Adds substantial context beyond annotations: requires an authenticated session and an idempotency_key, and is strictly append-only ('cannot change code, permissions, flags or budgets'). This complements idempotentHint=true and destructiveHint=false with concrete operational constraints.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

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

Dense but front-loaded, opening with the core action and then the conditional field requirements, scope limits, and sibling routing. Each clause earns its place, though the sentence is long.

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 complex, nested, multi-operation tool with no output schema, the description covers auth, operation modes, required fields, and safety limits well. Return-value format is not described, but no output schema exists to defer to.

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%, so the baseline is 3; the description adds value by summarizing the operation-conditional required fields (propose vs challenge vs adopt) and flagging the auth/idempotency_key requirement in prose.

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?

States a specific verb (record) and resource (protocol proposal, challenge or adoption receipt) and enumerates the three operation modes, making it immediately distinguishable from evaluate_protocol_upgrade and govern_cassie_world.

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?

Explicitly routes declarative response-contract evaluation to evaluate_protocol_upgrade and notes unsupported candidates remain inconclusive. It states per-operation required fields but does not give explicit when-not-to-use conditions for each operation mode.

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

All Cassie Hour tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?