Skip to main content
Glama
naw103

Foremerge

by naw103
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Rust
Local

Publish intent

publish_intent

Announce upcoming code changes and affected scopes to detect conflicts with other agents' work before editing. Returns immediate conflicts and related intents for assessment.

Instructions

Announce work you are about to do, and the scopes it will change, before editing any code. This is the first call for every task, after register_agent. The intent is stored with status INTENT and compared against every other active intent. Returns the intent (with its int_ id), any conflicts detected immediately, and related_work: active intents, your own others included, that may relate to yours. Entries with asserted: true are collisions with both declared operations stated; the rest are candidates, with why_surfaced saying why. Assess each related_work entry and call record_assessment before writing code, then claim_work and start_work. Use check_conflicts instead for a what-if check that stores nothing.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
taskYesShort name of the task this belongs to, for example payments-provider. Intents with the same task text share one task record.
scopesNoEvery scope this work will touch, each with the operation performed on it. Conflict detection relies on these, so declare them all.
summaryYesWhat you are going to change, in one sentence.
agent_idYesYour agent id (agt_...) from register_agent.
metadataNoOptional JSON object of extra context stored with the intent.
rationaleNoOptional reason for the change.
depends_onNoIntent ids (int_...) this work relies on, recorded for the coordination graph and reported as dependents by query_work. Not checked or enforced: to make acceptance require them, also list them in publish_changeset's dependencies.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed9 schema fields changedv0.4.3
    • addedInput schema / properties / agent_id / description
      Added value: +"Your agent id (agt_...) from register_agent."
    • addedInput schema / properties / depends_on / description
      Added value: +"Intent ids (int_...) this work relies on, recorded for the coordination graph and reported as dependents by query_work. Not checked or enforced: to make acceptance require them, also list them in publish_changeset's dependencies."
    • addedInput schema / properties / metadata / description
      Added value: +"Optional JSON object of extra context stored with the intent."
    • addedInput schema / properties / rationale / description
      Added value: +"Optional reason for the change."
    • addedInput schema / properties / scopes / description
      Added value: +"Every scope this work will touch, each with the operation performed on it. Conflict detection relies on these, so declare them all."
    • addedInput schema / properties / scopes / items / properties / key / description
      Added value: +"The name within that kind, for example PaymentService, POST /orders, or src/billing.rs. Comparison is case-insensitive."
    • addedInput schema / properties / scopes / items / properties / kind / description
      Added value: +"What sort of thing the scope names: a code symbol, an API route, a data schema, a config key, infrastructure, a test, a migration, an environment variable, a file path, a component, a contract, or a broader domain."
    • addedInput schema / properties / summary / description
      Added value: +"What you are going to change, in one sentence."
    • addedInput schema / properties / task / description
      Added value: +"Short name of the task this belongs to, for example payments-provider. Intents with the same task text share one task record."
  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?

Annotations are all false, providing minimal safety signals. The description carries the full behavioral burden and delivers: it states the intent is stored with status INTENT, compared against all active intents, returns the intent ID, detected conflicts, and related_work with asserted vs candidate semantics. It also explains side effects on the coordination graph via depends_on, all without contradicting the annotations.

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 dense but every sentence earns its place: it states the purpose, positions the tool in the workflow, explains the return semantics, and gives the alternative. It is front-loaded with the core purpose and avoids redundancy. No wasted words.

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 (7 params, nested scopes object, no output schema), the description is remarkably complete: it covers the intent lifecycle, return structure (intent ID, conflicts, related_work with asserted/candidate logic), and the required next steps. It also clarifies the depends_on parameter's role in the coordination graph and references the alternative tool. An agent has everything needed to call it correctly and integrate it with the surrounding workflow.

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 every parameter is well-documented in the schema itself. The description does not add new parameter-level meaning beyond what the schema already provides—it reinforces the purpose of scopes (conflict detection) but that is also stated in the schema's scopes description. Thus 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 ('Announce') and a clear resource ('work you are about to do, and the scopes it will change'), immediately stating the tool's purpose. It distinguishes itself from siblings by explicitly positioning it as 'the first call for every task, after register_agent' and naming check_conflicts as a what-if alternative.

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 gives explicit when-to-use guidance: 'before editing any code' and 'the first call for every task'. It also prescribes the follow-up sequence (record_assessment, claim_work, start_work) and clearly states when NOT to use it, directing the agent to check_conflicts instead for a non-storing what-if check.

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