Skip to main content
Glama

Delegate a contract to Reasonix

reasonix_delegate
Destructive

Delegate a user-approved task contract to an isolated edit worker with scoped write permissions and sandboxed execution, enabling safe code changes.

Instructions

After explicit user approval, delegate one immutable TaskContractV1 to an isolated Reasonix edit worker. For a trivial edit whose local context is already verified, do one focused preflight and delegate directly; do not browse docs or memory solely to construct the contract. write_scope is the exclusive write allowlist and already denies every other path. forbidden_scope is only for sensitive carve-outs inside broader write scopes; never use **/* or another catch-all that matches a concrete write_scope target. Default wait_mode=review holds this call until review, interaction, failure, or timeout; a wait timeout is recoverable and does not cancel the worker. New tasks default to worker_lane=fast (direct edits; no Goal, AutoResearch, review/task skills, or subagents); use worker_lane=deep only for explicitly long-horizon delivery/goal work. Select the lowest reasoning_effort adequate for the task (low is the lowest supported). Set execution_timeout_seconds proportionately (fast default 600, deep default 3600, maximum 14400); omitted resumes retain the stored deadline. Use background only when the caller intentionally wants asynchronous recovery flow. Contract verification and allowed_commands run as exact static argv with no shell: sh -c/bash -c/eval, pipes, redirection, and inline interpreters are rejected. For byte-exact file content, use file_assertions instead of shell comparison commands.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
resumeNo
task_idYes
base_refNo
contractYes
path_baseNoDefaults to cwd for new tasks; omitted legacy resumes preserve stored semantics.
wait_modeNoreview
worker_laneNoWorker execution lane. fast (default) is a direct-edit Reasonix session without Goal/AutoResearch/subagents; deep is an explicit long-horizon Goal session. Omitted resumes preserve the stored lane.
pause_revisionNo
reasoning_effortNoReasoning effort; low is the lowest supported value for new tasks.
pause_reason_hashNo
wait_timeout_secondsNo
execution_timeout_secondsNoTask execution deadline. New fast-lane tasks default to 600 seconds and deep-lane tasks to 3600 seconds; omitted resumes preserve the stored value. A wait timeout never cancels the worker.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
diffNo
phaseYes
risksNo
stateYes
usageNo
branchYes
reasonNo
summaryNo
task_idYes
worktreeYes
diff_statNo
timed_outNo
session_idNo
updated_atYes
commit_hashNo
worker_laneYes
changed_filesNo
contract_hashYes
repair_roundsYes
repository_idYes
pause_revisionNo
resume_requiredNo
review_revisionNo
inspect_requiredNo
review_tree_hashNo
source_collisionNo
pause_reason_hashNo
active_interactionNo
reasonix_work_modeNo
review_diff_sha256No
integration_commandNo
reasonix_session_modeNo
required_review_criteriaNo
execution_timeout_secondsYes
effective_reasoning_effortYes
requested_reasoning_effortYes
source_checkout_integratedYes
Behavior5/5

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

The description goes well beyond annotations by disclosing key behaviors: write_scope is an exclusive allowlist, forbidden_scope is only for sensitive carve-outs, commands are exact static argv with no shell/pipes/redirection, wait_timeout is recoverable and does not cancel the worker, and omitted resumes preserve stored settings. It also notes the requirement for 'explicit user approval,' which is critical context. No contradiction with annotations.

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 description is dense and front-loaded with the core purpose, followed by practical operational rules. It is longer than ideal and runs as a single block of text, but every sentence adds substantive guidance—defaults, constraints, and security invariants—so the length is justified.

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 tool's complexity (12 parameters, nested contract object, multiple enums, output schema, annotations), the description covers the most decision-relevant aspects: task scoping, worker behavior, timeouts, resume semantics, and command execution security. It gives enough context for an agent to select and invoke the tool correctly without requiring external documentation.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is only 33%, but the description compensates richly. It explains the semantics of write_scope and forbidden_scope, defaults for wait_mode, worker_lane, reasoning_effort (low is lowest), execution_timeout_seconds defaults (fast 600, deep 3600, max 14400), and advises file_assertions for byte-exact content. This adds meaning far beyond raw schema names.

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 specific action: 'delegate one immutable TaskContractV1 to an isolated Reasonix edit worker' after explicit user approval. This clearly distinguishes the tool from siblings (inspect, control) by naming the delegated contract workflow and the worker isolation.

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 strong situational guidance: for trivial edits with verified local context, do one focused preflight and delegate directly; avoid browsing docs/memory solely to construct the contract. It also differentiates worker_lane=fast versus deep, explains background mode, and specifies when deep is needed ('explicitly long-horizon delivery/goal work').

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

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/rixzkiye/codex-reasonix-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server