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 has a clearly distinct role in the contract lifecycle: dispatch, poll/claim, extend, release, fulfill, fail, inspect, and verify. The descriptions explicitly state when NOT to use a tool and point to the correct alternative, eliminating overlap. The only close pair, inspect_mesh_state and verify_contract, is cleanly separated by scope: mesh-wide read-only status vs. on-disk pointer baseline audit.
All tool names follow a predictable snake_case verb_noun pattern: inspect_mesh_state, poll_next_task, release_contract, extend_ttl, verify_contract, dispatch_contract, fulfill_contract, fail_contract. The few multi-word names remain readable and consistent with the convention.
Eight tools is well-scoped for a multi-agent contract queue. Every tool maps to a necessary lifecycle action or diagnostic check, with no redundant or filler operations. The surface is neither too thin nor bloated.
The lifecycle is nearly complete: create, claim, renew, release, verify, complete, fail, and inspect all exist with terminal state handling. Minor gaps remain, such as a requester-side cancel/revoke for a SUBMITTED contract before it is claimed, and cleanup/maintenance operations. These can be worked around via TTL expiry but are noticeable omissions.