Cromanion

cromanion_ask_human

Idempotent

Ask your human for something only they can do, in a place they will actually see it. Every other refusal here ends with YOU reading it — a permission they did not grant, a payment you cannot make, a mode you may not set — and from their side you simply went quiet. This puts one request on their notifications screen, attributed to you. Nothing replies here: they act in their console, and you find out by reading cromanion_grants or cromanion_config again. One request an hour, and a second from you replaces the first rather than stacking.

Input Schema

TableJSON Schema

Name	Required	Description
`body`	Yes	Why you need it and what it unblocks, in a sentence or two. Up to 400 characters.
`title`	Yes	What you need, in a line they can read at a glance. Up to 90 characters.
`siteId`	No	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.

Output Schema

TableJSON Schema

Name	Required	Description
`ok`	Yes
`note`	No	Where it landed, and that nothing answers back here.
`asked`	Yes

Schema Changelog

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

Changed1 schema field changedSep 7, 2026

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"
+}

AddedSep 7, 2026

TDQS

A4.4/5.0

Behavior5/5

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

The description adds substantial behavioral context beyond the annotations: the request appears on the human's notification screen, is attributed to the agent, receives no inline reply, and replaces a prior request rather than stacking. It also tells the agent to re-read cromanion_grants or cromanion_config to see the outcome, which is essential for this async tool.

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?

The first sentence states the purpose immediately, and subsequent sentences explain when to use it, what happens after invocation, and the rate limiting. It is slightly rhetorical in the middle, but every sentence contributes useful decision-making or behavioral information.

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 an unusual asynchronous human-interaction tool, the description is complete: it explains the delivery channel, attribution, lack of inline response, how to observe the result, and the request rate limit. The output schema exists, and the description correctly tells the agent not to expect a direct reply.

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?

Schema coverage is 100% and each parameter already has a meaningful description. The tool description does not add parameter-specific semantics, so the baseline score of 3 applies.

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 opens with a concrete action and resource: asking the human for something only they can do, delivered to their notifications screen. It also distinguishes this tool from the broader refusal/error path in sibling tools by contrasting permission, payment, and mode blocks that otherwise end with the agent reading the result.

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?

It gives clear applicable scenarios: human-only actions like granting permissions, making payments, or setting modes that the agent cannot perform. It also explains follow-up behavior, the one-request-per-hour limit, and replacement semantics, though it does not explicitly list alternative sibling tools by name.

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.

Resources

Need Help?