Cromanion

cromanion_decide

Idempotent

Rule on one thing from cromanion_pending: pass its kind and id back unchanged with a decision. approve / reject for everything; pause additionally for a playbook rule. Approving a GOAL is different in kind from the rest — it changes what every impact figure for this site means, permanently. You cannot edit rule text here, only rule on it.

Input Schema

TableJSON Schema

Name	Required	Description
`id`	No	The item's id, exactly as cromanion_pending returned it. Ids are not shared across kinds.
`all`	No	Rule on every discovered page at once, ignoring `id`. observed_path only — the other kinds are decided one at a time, as in the console.
`kind`	Yes	Which queue the item came from. Copy it back from cromanion_pending unchanged.
`decision`	Yes	A status and nothing else — rule TEXT is edited by cromanion_set_playbook. `pause` applies only to a playbook_rule.

Output Schema

TableJSON Schema

Name	Required	Description
`id`	No
`ok`	Yes
`kind`	Yes
`ruled`	No	Present with `all`: how many were ruled on. Zero is a success — there was nothing waiting.
`summary`	No	What the ruling changed, in one line you can repeat to your human.
`decision`	Yes

Schema Changelog

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

Changed5 schema fields changedSep 6, 2026

addedInput schema / properties / all

Added value: +{
+  "description": "Rule on every discovered page at once, ignoring `id`. observed_path only — the other kinds are decided one at a time, as in the console.",
+  "type": "boolean"
+}

changedInput schema / properties / decision / description

Previous value: -"A status and nothing else — there is no way to edit an item's text here. `pause` applies only to a playbook_rule."New value: +"A status and nothing else — rule TEXT is edited by cromanion_set_playbook. `pause` applies only to a playbook_rule."

changedInput schema / required

Previous value: -[
-  "kind",
-  "id",
-  "decision"
-]New value: +[
+  "kind",
+  "decision"
+]

addedOutput schema / properties / ruled

Added value: +{
+  "description": "Present with `all`: how many were ruled on. Zero is a success — there was nothing waiting.",
+  "type": "number"
+}

changedOutput schema / required

Previous value: -[
-  "ok",
-  "kind",
-  "id",
-  "decision"
-]New value: +[
+  "ok",
+  "kind",
+  "decision"
+]

Changed1 schema field changedSep 6, 2026

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "properties": {
+    "decision": {
+      "enum": [
+        "approve",
+        "reject",
+        "pause"
+      ],
+      "type": "string"
+    },
+    "id": {
+      "type": "string"
+    },
+    "kind": {
+      "enum": [
+        "edit_genre",
+        "playbook_rule",
+        "goal",
+        "observed_path"
+      ],
+      "type": "string"
+    },
+    "ok": {
+      "type": "boolean"
+    },
+    "summary": {
+      "description": "What the ruling changed, in one line you can repeat to your human.",
+      "type": "string"
+    }
+  },
+  "required": [
+    "ok",
+    "kind",
+    "id",
+    "decision"
+  ],
+  "type": "object"
+}

Changed3 schema fields changedSep 6, 2026

addedInput schema / properties / decision / description

Added value: +"A status and nothing else — there is no way to edit an item's text here. `pause` applies only to a playbook_rule."

addedInput schema / properties / id / description

Added value: +"The item's id, exactly as cromanion_pending returned it. Ids are not shared across kinds."

addedInput schema / properties / kind / description

Added value: +"Which queue the item came from. Copy it back from cromanion_pending unchanged."

First observedSep 6, 2026

TDQS

A4.9/5.0

Behavior5/5

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

The description discloses an important side effect not fully captured by annotations: approving a GOAL permanently changes what every impact figure for the site means. It also clarifies the scope of the pause decision. This goes beyond the readOnlyHint and destructiveHint annotations, providing the agent with necessary information about consequences.

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 concise and well-structured. It flows logically: what to do, which decisions apply, a special warning about GOAL, and a final note about what cannot be done. Every sentence contributes meaning without redundancy or excessive length.

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 the rich schema, annotations, and output schema, the description is complete. It covers the tool's action, source of data, decision constraints, side effects, and exclusions. An agent has all necessary context to use this tool correctly without ambiguity.

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% with descriptions for all four parameters, so the baseline is 3. The description adds meaning by reinforcing that id and kind must be returned unchanged from cromanion_pending and by clarifying the relationship between decision and kind (pause only for playbook_rule, approve/reject for everything). This adds value beyond the schema's own descriptions.

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's purpose: to rule on one pending item by passing back its kind and id unchanged with a decision. It distinguishes this from editing rule text, which is handled by cromanion_set_playbook, and specifies the decision values. The source queue (cromanion_pending) is explicitly mentioned, making the action unambiguous.

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 clear usage guidance: it tells the agent to copy kind and id from cromanion_pending, explains that pause applies only to playbook_rule, and warns that approving a GOAL has a permanent effect on impact figures. It also explicitly states that rule text cannot be edited here, directing the agent to the correct sibling tool for that operation.

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

All Cromanion tools Inspect

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

A4/5.0

Disambiguation4/5

Most tools target a distinct resource or workflow, and the set_*/add_*/claim_* groups are well separated by their descriptions. The main risk is the cluster of open_claim, verify_claim, and claim_domain, but their lifecycle roles are clearly differentiated.

Naming Consistency4/5

All tools share the cromanion_ prefix and use snake_case, with a strong verb_noun pattern in actions like set_brand, add_goal, and verify_claim. A few resource-style names such as impact, pending, site_status, and surfaces break the pattern slightly, but not enough to cause real confusion.

Tool Count4/5

17 tools is slightly above the usual 3-15 range, but the server covers onboarding, configuration, approvals, measurement, and billing, and each tool addresses a distinct operation. No tool feels redundant, so the count is defensible if a bit heavy.

Completeness3/5

The core workflows are covered: claim/verify, configure, review pending items, decide, and read impact. However, there are no read/retrieve endpoints for current brand, voice, mode, holdout, or goal settings, and add_goal lacks a matching list/delete operation, leaving agents unable to audit or undo configuration.

Resources

Need Help?