Skip to main content
Glama
Sign In

Cromanion

by com.cromanion
OverviewDiscussionsAdmin

cromanion_set_playbook

Destructive

Reword a distilled rule, or ask for a fresh distillation. Rules are what the agent learned from real sessions; cromanion_decide approves or pauses them, and this changes what they SAY. Send a ruleId with condition and/or recommendedAction to reword one — ids come from cromanion_config, which also shows rules you have already approved or paused. Send redistill: true instead to distil new rules from recent sessions; they arrive as proposed for you to rule on. Rate-limited to one distillation an hour. Needs the decisions permission.

Input Schema

NameRequiredDescriptionDefault
ruleIdNoThe rule to reword, from cromanion_config.
siteIdNoWhich site this call is about. Only needed when your credential covers more than one — cromanion_grants lists them and says whether it is required. Omitting it with several is refused rather than guessed at.
conditionNoWhen the rule applies, in plain words. Omit to leave it.
redistillNoIgnore ruleId and distil fresh rules from recent sessions instead.
recommendedActionNoWhat the agent should do when it applies. Omit to leave it.

Output Schema

NameRequiredDescriptionDefault
okYes
noteNo
ruleIdNo
changedNoFalse when the wording was already what you sent.
newRulesNoProposals that did not exist before this run.
sessionsNoFinished sessions the distillation read.
conditionNo
redistilledNoFalse when there was nothing to distil (no finished sessions yet).
recommendedActionNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed3 schema fields changed
    • addedOutput schema / properties / newRules
      Added value: +{
+  "description": "Proposals that did not exist before this run.",
+  "type": "integer"
+}
    • addedOutput schema / properties / redistilled / description
      Added value: +"False when there was nothing to distil (no finished sessions yet)."
    • addedOutput schema / properties / sessions
      Added value: +{
+  "description": "Finished sessions the distillation read.",
+  "type": "integer"
+}
  2. Changed1 schema field changed
    • addedInput schema / properties / siteId
      Added value: +{
+  "description": "Which site this call is about. Only needed when your credential covers more than one — cromanion_grants lists them and says whether it is required. Omitting it with several is refused rather than guessed at.",
+  "type": "string"
+}
  3. Added

TDQS

A4.9/5.0
Behavior5/5

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

Beyond the destructiveHint annotation, the description discloses that rewording changes what rules say, that newly distilled rules arrive as 'proposed', that there is a rate limit, and that a specific permission is required. This adds meaningful behavioral context without contradicting annotations.

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?

Five sentences, all information-dense and front-loaded with the core purpose. It uses inline code and references to sibling tools efficiently, 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?

Given an output schema exists, the description needn't explain return values. It covers purpose, invocation modes, alternatives, prerequisites, side effects, rate limits, and output status. Nothing essential is missing for correct tool selection and invocation.

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 parameters are already documented. The description adds valuable cross-references: ruleId comes from cromanion_config, siteId is only needed when credentials cover multiple sites and is confirmed via cromanion_grants, and redistill ignores ruleId. This is a strong supplement, though condition and recommendedAction rely mostly on 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 states specific actions: reword a distilled rule or ask for a fresh distillation. It differentiates from siblings by explicitly contrasting with cromanion_decide (approves/pauses) and cromanion_config (lists rule ids), and notes this tool changes what rules say. An agent can clearly identify when to use this tool.

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?

It explicitly says when to send ruleId with condition/recommendedAction vs redistill: true, names where ids come from (cromanion_config), mentions the prerequisites (decisions permission), and notes the rate limit of one distillation per hour. It also routes newly distilled 'proposed' rules to cromanion_decide for ruling.

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

All Cromanion toolsInspect
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