Skip to main content
Glama
naw103

Foremerge

by naw103
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Rust
Local

Coordinate with another agent

coordinate_with_agent

Send a stored message to another agent to agree how overlapping work should coexist. Use when a conflict is detected; linking a conflict ID changes its status to COORDINATING.

Instructions

Send a stored message to another registered agent, usually to agree how two overlapping pieces of work should coexist. Use it when check_conflicts or related_work shows a clash you need the other agent to act on; afterwards, a party to the conflict records the agreement with resolve_conflict, naming this message's id. Linking a conflict_id moves that conflict from OPEN to COORDINATING. The message is appended to a durable log with status UNREAD; it does not interrupt or control the other agent. No MCP tool reads messages: the recipient reads them with the CLI, foremerge coordinate inbox. Returns the stored message, including its msg_ id.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
messageYesWhat you propose or need, in plain language.
conflict_idNoOptional stored conflict (cfl_...) this message is about. An eph_ id from a what-if check_conflicts is rejected with NOT_FOUND. May be combined with changeset_id.
to_agent_idYesThe recipient's agent id (agt_...), for example the owner of the conflicting intent.
changeset_idNoOptional ChangeSet (chg_...) this message is about. Must exist.
from_agent_idYesYour agent id (agt_...).

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed5 schema fields changedv0.4.3
    • addedInput schema / properties / changeset_id / description
      Added value: +"Optional ChangeSet (chg_...) this message is about. Must exist."
    • addedInput schema / properties / conflict_id / description
      Added value: +"Optional stored conflict (cfl_...) this message is about. An eph_ id from a what-if check_conflicts is rejected with NOT_FOUND. May be combined with changeset_id."
    • addedInput schema / properties / from_agent_id / description
      Added value: +"Your agent id (agt_...)."
    • addedInput schema / properties / message / description
      Added value: +"What you propose or need, in plain language."
    • addedInput schema / properties / to_agent_id / description
      Added value: +"The recipient's agent id (agt_...), for example the owner of the conflicting intent."
  2. First observedv0.1.0

TDQS

A4.7/5.0
Behavior5/5

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

The description goes well beyond the uninformative all-false annotations, disclosing that the message is appended to a durable log with status UNREAD, that it does not interrupt or control the recipient, that linking a conflict_id moves it from OPEN to COORDINATING, and that no MCP tool reads messages. It also states the return value includes the stored message and its msg_ id.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is longer than typical but every sentence carries distinct information: purpose, trigger, follow-up action, state transition, durability, non-interruptive nature, and return value. It is deliberately structured and front-loaded with the core operation, with no filler or repetition.

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?

Despite lacking an output schema, the description explicitly states what is returned. It covers the integration with sibling tools, the state change on conflict_id, the durable status semantics, and the limitation that only the CLI can read messages. This is a complete briefing for a tool with this complexity.

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

Parameters3/5

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

Schema description coverage is 100%, so the schema fully documents all five parameters. The description adds a bit of contextual meaning (e.g., conflict_id linking moves the conflict, eph_ ids are rejected), but most parameter semantics already appear in the schema, so a baseline 3 is appropriate.

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 and resource: 'Send a stored message to another registered agent,' and immediately states the purpose—'to agree how two overlapping pieces of work should coexist.' It also differentiates from siblings by referencing check_conflicts and resolve_conflict, clarifying this tool is for the message-sending step, not conflict detection or resolution.

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?

Explicit guidance is given: 'Use it when check_conflicts or related_work shows a clash you need the other agent to act on.' It also explains the follow-up flow with resolve_conflict and names the message id, and notes that the recipient reads via CLI since no MCP tool reads messages. This fully covers when and how to use the tool relative to alternatives.

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