Skip to main content
Glama

continuum_intercept_action

Request permission before external side effects and prevent duplicate actions by tracking a stable operation key; if a prior attempt was interrupted, stop for human review.

Instructions

Ask permission before performing an external side effect (creating an issue, sending a message, charging a card). Returns proceed=true if you should do it, or proceed=false with the previous result if it was already done; do NOT repeat it in that case. If a previous attempt was interrupted, returns proceed=false with status='unknown': the effect may or may or may not have happened, so stop and ask a human. After performing the action, always call continuum_complete_action.

Pass a stable key identifying the specific operation (for example the invoice id or external resource id), not incidental formatting. The key is what makes two attempts count as the same action, so reuse the exact same key for the same operation across sessions; a key derived from the resource identity makes deduplication immune to argument formatting differences (relative vs absolute paths, argument naming, and so on).

Input Schema

NameRequiredDescriptionDefault
keyNo
grantNo
run_idYes
pinningNo
argumentsNo
action_typeYes
scoped_to_runNo

Output Schema

NameRequiredDescriptionDefault
resultYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.2

TDQS

A4.3/5.0
Behavior4/5

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

The only annotation is readOnlyHint=false, so the description carries nearly the full burden and does so well: it discloses the proceed/unknown return semantics and the interruption behavior that could otherwise cause duplicate side effects. It does not discuss auth/grant requirements or failure/error modes beyond the interrupted case.

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?

Front-loaded with the decision rule and outcomes in the first sentences, then a focused second paragraph on the deduplication key. It is slightly long and contains a typo ('may or may or may not'), but every sentence carries decision-relevant information.

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?

An output schema exists, yet the description still usefully explains the return contract, and the interrupt/duplicate workflow is fully covered. The residual gap is behavioral detail on the optional control parameters (grant, pinning, scoped_to_run), which an agent would have to infer.

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 0% and there are 7 parameters, so the description must compensate. It does an excellent job on `key` (stable identity, reuse across sessions, formatting-immunity rationale), but `run_id`, `action_type`, `grant`, `pinning`, `arguments`, and `scoped_to_run` are left entirely undocumented — notably `grant`, which likely governs authorization for the action.

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 action and intent: ask permission before an external side effect, with concrete examples (creating an issue, sending a message, charging a card). It also names the follow-up tool continuum_complete_action, which cleanly separates it from continuum_fail_action and continuum_reconcile_action.

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?

Explicit routing for every outcome: do it when proceed=true, do NOT repeat when proceed=false with a prior result, and stop and ask a human when status='unknown'. It also mandates the post-action call to continuum_complete_action, leaving no ambiguity about sequencing.

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