Skip to main content
Glama

dispatch_contract

Dispatches code review, audit, implementation, or test contracts to another local AI agent, creating SHA-256 file snapshots and a baseline for cross-host verification.

Instructions

Dispatch a task or code review contract to another local AI agent host via the shared SQLite WAL mesh.

Purpose

Registers a new contract in SUBMITTED status with full-file SHA-256 fingerprint snapshots of all target files, establishing an immutable baseline for cross-host verification.

Usage Guidelines

  • When to use: Use when requesting code reviews, architecture audits, implementation, or test generation from a target agent (e.g., target_agent="workbuddy" or "antigravity").

  • When NOT to use:

    • Do NOT use to claim or execute tasks (use poll_next_task).

    • Do NOT use to check task status or inspect outputs (use inspect_mesh_state).

    • Do NOT use if the target host does not share the same local filesystem access to workspace_root.

  • Prerequisites: workspace_root must be a valid directory accessible by both hosts. Pointer files must exist on disk and be saved. Sensitive files (.env, keys, credentials, .git/config) and path escapes are strictly blocked.

Behavior & Side Effects

  • Mutates database: Synchronously inserts a single row into contracts with status='SUBMITTED' in SQLite WAL (~/.ferrycat/mesh.db).

  • SHA-256 Snapshot: Computes 64-char hex SHA-256, byte size, and first/last lines for each pointer. Emits a warning if any file was modified within the last 3 seconds (indicating unsaved IDE buffers).

  • Lifecycle & Expiry: Starts the queue_ttl_sec countdown (default: 1800s / 30m). If the target agent never claims it before queue_ttl_sec elapses, the contract lazily transitions to TIMED_OUT.

  • Once claimed, execution is governed by exec_ttl_sec (tiered default: 1800s for review/audit, 300s for implementation/test).

Return Value

Returns { contract_id: string, status: 'SUBMITTED', created_at: number, files: Array<{ path, size, mtime_ms, sha256, first_line, last_line, line_range? }>, warning?: string }. Note: requester_agent / target_agent / task_type / title / TTLs are NOT echoed back — read them via inspect_mesh_state if needed.

Input Schema

NameRequiredDescriptionDefault
titleYesConcise contract title (1-120 chars) summarizing the goal of the request.
pointersYesArray of 1 to 50 target file pointers hashed with full-file SHA-256 and snapshot boundaries for tamper detection.
task_typeYesType of contract task. Tiered default execution TTL: 1800s for code_review/architecture_audit, 300s for implementation/test_generation.
exec_ttl_secNoExecution TTL in seconds once CLAIMED (default: 1800s for review/audit, 300s for implementation/test). Worker must fulfill, extend, release, or fail within this window.
target_agentYesTarget worker agent identifier expected to claim and execute this contract (e.g., "workbuddy", "antigravity").
queue_ttl_secNoQueue expiration TTL in seconds while status is SUBMITTED (default: 1800s / 30m). Transitions to TIMED_OUT if unclaimed before expiry.
workspace_rootYesAbsolute canonical path to the shared local workspace directory accessible by both hosts (e.g. "F:/git/FerryCat"). Path escapes and sensitive files are blocked.
context_summaryYesDetailed task instructions, audit focus areas, architectural constraints, and background context for the worker agent (1-20000 chars).
contract_schemaNoOptional Draft-07 JSON Schema that structured_output must validate against. Bounded to 1MB and max 32 depth (FC-302).
requester_agentNoRequester agent identifier. Defaults to AGENT_NAME env var (e.g., "antigravity", "workbuddy").

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv0.3.2
    • changedInput schema / properties / contract_schema / description
      Previous value: -"Optional Draft-07 JSON Schema that structured_output must validate against. Enforces bounded retry (max 2 RETRY_NEEDED attempts before terminal VALIDATION_FAILED)."New value: +"Optional Draft-07 JSON Schema that structured_output must validate against. Bounded to 1MB and max 32 depth (FC-302)."
  2. Changed12 schema fields changedv0.3.0
    • changedInput schema / properties / context_summary / description
      Previous value: -"Task instructions, audit focus, and background context"New value: +"Detailed task instructions, audit focus areas, architectural constraints, and background context for the worker agent (1-20000 chars)."
    • changedInput schema / properties / contract_schema / description
      Previous value: -"Optional JSON Schema that the worker structured_output must satisfy"New value: +"Optional Draft-07 JSON Schema that structured_output must validate against. Enforces bounded retry (max 2 RETRY_NEEDED attempts before terminal VALIDATION_FAILED)."
    • changedInput schema / properties / exec_ttl_sec / description
      Previous value: -"Execution expiration TTL in seconds for CLAIMED state (default: 300)"New value: +"Execution TTL in seconds once CLAIMED (default: 1800s for review/audit, 300s for implementation/test). Worker must fulfill, extend, release, or fail within this window."
    • changedInput schema / properties / pointers / description
      Previous value: -"File pointers to be hashed and verified on the worker side (max 50 files)"New value: +"Array of 1 to 50 target file pointers hashed with full-file SHA-256 and snapshot boundaries for tamper detection."
    • changedInput schema / properties / pointers / items / properties / line_range / description
      Previous value: -"Optional [startLine, endLine] 1-based inclusive range"New value: +"Optional [startLine, endLine] 1-based inclusive line range focus for the task."
    • changedInput schema / properties / pointers / items / properties / path / description
      Previous value: -"File path relative to workspace_root"New value: +"File path relative to workspace_root. Must exist on disk. Sensitive files (.env*, *.pem, *.key, id_rsa*, *credentials*, *secret*, .npmrc, .git/config) and path escapes are strictly rejected."
    • changedInput schema / properties / queue_ttl_sec / description
      Previous value: -"Queue expiration TTL in seconds for SUBMITTED state (default: 1800)"New value: +"Queue expiration TTL in seconds while status is SUBMITTED (default: 1800s / 30m). Transitions to TIMED_OUT if unclaimed before expiry."
    • changedInput schema / properties / requester_agent / description
      Previous value: -"Requester agent identifier (defaults to AGENT_NAME env var, e.g., \"antigravity\")"New value: +"Requester agent identifier. Defaults to AGENT_NAME env var (e.g., \"antigravity\", \"workbuddy\")."
    • changedInput schema / properties / target_agent / description
      Previous value: -"Target worker agent identifier (e.g., \"workbuddy\", \"antigravity\")"New value: +"Target worker agent identifier expected to claim and execute this contract (e.g., \"workbuddy\", \"antigravity\")."
    • changedInput schema / properties / task_type / description
      Previous value: -"Type of contract task"New value: +"Type of contract task. Tiered default execution TTL: 1800s for code_review/architecture_audit, 300s for implementation/test_generation."
    • changedInput schema / properties / title / description
      Previous value: -"Concise contract title"New value: +"Concise contract title (1-120 chars) summarizing the goal of the request."
    • changedInput schema / properties / workspace_root / description
      Previous value: -"Absolute path to the shared local workspace root directory"New value: +"Absolute canonical path to the shared local workspace directory accessible by both hosts (e.g. \"F:/git/FerryCat\"). Path escapes and sensitive files are blocked."
  3. First observedv0.1.0

TDQS

A4.8/5.0
Behavior5/5

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

With no annotations, the description carries the full burden and does so thoroughly: it discloses the database mutation (a single row insert into contracts at ~/.ferrycat/mesh.db), the SHA-256 snapshot computation, a stale-buffer warning heuristic (files modified within 3 seconds), and the full lazy-expiry lifecycle with tiered TTLs. This is exactly the behavioral context an agent needs before a mutating call.

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 markdown sectioning (Purpose / Usage Guidelines / Behavior & Side Effects / Return Value) makes the length appropriate for a 10-parameter mutating tool, and the purpose is front-loaded. There is some redundancy — sensitive-file blocking is stated in both the description body and repeated again in the schema — which keeps it from a 5.

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?

Although there is no output schema, the description explicitly enumerates the return shape ({contract_id, status, created_at, files[...], warning?}) and even flags fields that are omitted from the response. Combined with the lifecycle and failure-mode detail, nothing an agent needs to invoke this correctly is missing.

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 the schema already documents all 10 parameters and the baseline would be 3. The description adds value beyond it by explaining the tiered TTL defaults tied to task_type, and by noting that requester_agent/target_agent/TTLs are NOT echoed in the return value. It does not add much per-parameter syntax detail, so a 4 rather than a 5.

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 verb, resource, and mechanism ('Dispatch a task or code review contract to another local AI agent host via the shared SQLite WAL mesh') and immediately refines it ('Registers a new contract in SUBMITTED status with full-file SHA-256 fingerprint snapshots'). This is clearly distinct from siblings like poll_next_task and inspect_mesh_state, which are named as alternatives.

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?

It provides explicit 'When to use', 'When NOT to use' with named sibling alternatives (poll_next_task for claiming/executing, inspect_mesh_state for status), and prerequisites (shared filesystem access, pointer files saved on disk, sensitive-file blocking). Nothing is left to inference.

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