Skip to main content
Glama

conduyt_ai_execute_actions

Executes ready actions from a Conduyt plan using its single-use confirmation token, applying permissions, tenant scope, and audit controls and returning per-action results.

Instructions

Copilot actions — APPLY. Executes the ready actions from a conduyt_ai_plan_actions result through the same routes the UI uses (permissions, tenant scope, visibility, audit all apply). Send the plan's actions array back exactly as received plus its confirmationToken (single-use, expires in 5 minutes, bound to the caller and the exact set — any edit is refused). Optionally narrow with selectedIds. Returns a per-action result; drafts are not sent. Sending the same token again REPLAYS the run (nothing runs twice; the response says replayed:true). A result with inFlight:true was started but never confirmed — inspect the record, then resume it explicitly with resumeIds.

Input Schema

NameRequiredDescriptionDefault
actionsYesThe `actions` array from the plan, unmodified
resumeIdsNoRe-run actions the previous response reported with inFlight:true (started but never confirmed, e.g. the connection dropped mid-apply). Check the record first — the write may already exist — and only after the result's resumableAt (the earlier attempt can no longer be running); earlier resumes are refused. Later actions wait behind an in-flight one (plan order). Never re-run automatically.
selectedIdsNoFirst apply only: apply just these action ids (default: every ready action). A later call with the same token must resend the same selection — a run's action set cannot be widened.
confirmationTokenYesThe plan's confirmationToken

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv4.71.0

TDQS

A4.8/5.0
Behavior5/5

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

No annotations exist, so the description carries full burden and does: permissions/tenant scope/visibility/audit all apply, token is single-use, expires in 5 minutes, is bound to caller and exact action set, any edit is refused, drafts are not sent, and resending a token replays rather than re-runs (replayed:true). This is unusually complete disclosure of side effects and idempotency semantics.

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 APPLY purpose and packed with operative detail in a compact block; nearly every clause carries decision-relevant information. Slightly dense as a single paragraph, but no sentence is filler.

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 a mutation tool with no annotations and no output schema, the description supplies what is missing: execution semantics, token lifecycle, idempotency/replay behavior, and the shape of key return signals (per-action result, replayed:true, inFlight:true). Nothing an agent needs to call it safely is absent.

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 baseline is 3, but the description adds meaning beyond the schema's token one-liner: single-use, 5-minute expiry, bound to caller and exact set, and that replay is safe. selectedIds widening prohibition and resume ordering are also reinforced 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 (execute/apply) and resource (the ready actions from a conduyt_ai_plan_actions result), and explicitly names the sibling that produces its input. An agent can distinguish this APPLY step from the planning tool without inspecting either schema.

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?

Explicitly says when to use (after a plan, send the actions array plus token), how to narrow (selectedIds), how to resume (resumeIds after inFlight:true, only past resumableAt), and what not to do (never re-run automatically). The preconditions for resume are spelled out, not left to inference.

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

Deploy Server

Other Tools