FerryCat
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| AGENT_NAME | Yes | The name identifying the agent host that mounts the FerryCat MCP server (e.g. "antigravity", "workbuddy"). Configured per host in the host's MCP settings. |
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": true
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| dispatch_contractA | Dispatch a task or code review contract to another local AI agent host via the shared SQLite WAL mesh. PurposeRegisters 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
Behavior & Side Effects
Return ValueReturns { 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. |
| poll_next_taskA | Atomically claim the oldest pending SUBMITTED contract assigned to this agent and verify local file fingerprints. PurposeRetrieves and claims next available contract work for the current agent, transitioning it from SUBMITTED to CLAIMED. Usage Guidelines
Behavior & Side Effects
Return Value
|
| fulfill_contractA | Submit execution or review deliverables for a CLAIMED contract, with TOCTOU soft-failure buffering and Ajv JSON Schema validation. PurposeDelivers the final output of a task, verifies that the code baseline was not mutated during execution, validates structured payloads, and transitions the contract to terminal COMPLETED. Usage Guidelines
Behavior & Side Effects
Return ValueReturns { ok: boolean, contract_id: string, status: 'COMPLETED' | 'RETRY_NEEDED' | 'POINTER_STALE' | 'VALIDATION_FAILED', retry_count: number, max_retries: number, toctou_strike?: number, max_toctou_strikes?: number, dirty_files?: Array<{ path, reason, detail }>, validation_errors?: string[], message: string }. |
| inspect_mesh_stateA | Strictly read-only query of contracts, execution progress, outputs, diagnostic counters, and failure causes. PurposeProvides comprehensive observability into the multi-agent mesh state without acquiring database locks or mutating rows. Usage Guidelines
Behavior & Side Effects
Return ValueReturns { total_returned: number, contracts: Array<{ contract_id, requester_agent, target_agent, task_type, title, status, is_logically_expired, created_at, claimed_at, completed_at, retry_count, extend_count, release_count, toctou_strike, result_summary, structured_output, artifacts_pointers, error_reason, salvaged_result, verified_sha256 }> }. |
| release_contractA | Hand a CLAIMED contract back to the queue tail as SUBMITTED with a fresh queue window. PurposeAllows an agent holding a claimed task to safely release ownership back to the queue without failing or aborting the task. Usage Guidelines
Behavior & Side Effects
Return ValueReturns { ok: boolean, contract_id: string, status: 'SUBMITTED' | 'CLAIMED' | 'TIMED_OUT', release_count: number, max_releases: number, message: string }. |
| extend_ttlA | Heartbeat renewal for long-running execution: restarts the active execution window of a CLAIMED contract. PurposePrevents execution timeout during deep reasoning, extensive test execution, or complex multi-step refactoring by resetting the execution clock. Usage Guidelines
Behavior & Side Effects
Return ValueReturns { ok: boolean, contract_id: string, status: 'CLAIMED' | 'TIMED_OUT', claimed_at?: number, expires_at?: number, extend_count: number, max_extends: number, message: string }. |
| fail_contractA | Explicitly mark a CLAIMED contract as terminal FAILED with a mandatory failure reason. PurposeImmediately terminates a claimed task that cannot be completed, recording actionable diagnostic reasons and freeing the requester from waiting for the execution TTL to expire. Usage Guidelines
Behavior & Side Effects
Return ValueReturns { ok: boolean, contract_id: string, status: 'FAILED' | 'TIMED_OUT', message: string }. |
| verify_contractA | Read-only pre-flight consistency check (ADR-0004): audits on-disk pointer files against the baseline SHA-256 snapshot. PurposeEnables agents or automated scripts to verify that on-disk files match the contract's dispatched baseline before calling fulfill_contract, preventing accidental TOCTOU strikes. Usage Guidelines
Behavior & Side Effects
Return ValueReturns { ok: true, valid: boolean, fulfillable: boolean, contract_id: string, status: ContractStatus, target_agent: string, toctou_strike: number, max_toctou_strikes: number, dirty_files: Array<{ path, reason, detail }>, message: string }. NOTE: valid only means every pointer still matches its dispatched baseline. fulfillable additionally requires the contract to be CLAIMED. A contract that already went terminal (FAILED / POINTER_STALE / COMPLETED) can report valid=true while fulfillable=false, so branch on fulfillable rather than valid before calling fulfill_contract. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 8 tools
Each tool maps to a distinct lifecycle action (dispatch/create, poll/claim, fulfill, fail, release, extend, inspect, verify) with explicit 'do NOT use X, use Y' guidance that pre-empts confusion between close pairs like inspect_mesh_state vs verify_contract and extend_ttl vs release_contract. Boundaries are unusually crisp.
All eight names follow a consistent snake_case verb-first pattern (dispatch_contract, poll_next_task, fulfill_contract, fail_contract, release_contract, extend_ttl, inspect_mesh_state, verify_contract). Noun phrases vary slightly in length but the convention is uniform and predictable.
Eight tools cleanly cover one coherent domain (a cross-host contract queue). Every tool earns its place in the lifecycle — no redundant wrappers and no filler.
The lifecycle is nearly fully covered: create, claim, heartbeat, release, fail, deliver, plus read-only state and file-consistency inspection. The notable gap is a requester-side cancel/revoke for a SUBMITTED contract (the only remedy is waiting for queue TTL), which is a minor but real dead end.