Skip to main content
Glama
Sign In
FlowState by DialectForge

FlowState by DialectForge

Official
by dialectforge
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Hybrid

manage_links

Connect records and components across projects, flag conflicts, and propagate changes as update todos without editing other projects.

Instructions

Connect things across projects. add: a project uses a shared component (link_type=uses, target_project, target_component), depends on a project, two components are the same, records relate, or a record gets a URL (e.g. an issue). Then a change or decision logged on the shared component (log_work component=) gives each linked project an update todo and a 'changed since' line; FlowState never edits other projects. remove: by link_id or the add fields; kept as removed (manage_history undo, record_type=link). flag_conflict: two records disagree (topic, evidence); the user keeps one. list: read-only. Requires project. Returns the link, the card, or {links}.

Input Schema

NameRequiredDescriptionDefault
urlNoadd: an https URL to attach to the source record.
noteNoadd: a short note kept on the link.
modelNoModel name if known. Never guess.
topicNoflag_conflict: what they disagree about, in plain words.
actionYesThe operation; see the tool description.
item_idNoSource: the record's id.
link_idNoremove: the link's id (from list); or give the add fields instead.
projectYesThe source project, by name or id. Required.
evidenceNoflag_conflict: up to 2 snippets for the source record.
componentNoSource: a component of this project, by name.
item_typeNoSource: a record type, with item_id.
link_typeNoHow the source relates to the target: uses, depends_on, part_of, same_as, supersedes, subtask_of, blocks, about, or url.
target_idNoadd: the target record's id.
target_typeNoadd: a target record type, with target_id.
target_projectNoadd: the target project, by name or id.
include_removedNolist: also removed links.
target_evidenceNoflag_conflict: up to 2 snippets for the other record.
target_componentNoadd: a component name in the target project.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed5 schema fields changedv2.4.3
    • changedInput schema / properties / action / enum
      Previous value: -[
-  "add",
-  "remove",
-  "list"
-]New value: +[
+  "add",
+  "remove",
+  "list",
+  "flag_conflict"
+]
    • addedInput schema / properties / evidence
      Added value: +{
+  "description": "flag_conflict: up to 2 snippets for the source record.",
+  "items": {
+    "type": "string"
+  },
+  "type": "array"
+}
    • changedInput schema / properties / model / description
      Previous value: -"Your model name if you know it. Never guess."New value: +"Model name if known. Never guess."
    • addedInput schema / properties / target_evidence
      Added value: +{
+  "description": "flag_conflict: up to 2 snippets for the other record.",
+  "items": {
+    "type": "string"
+  },
+  "type": "array"
+}
    • addedInput schema / properties / topic
      Added value: +{
+  "description": "flag_conflict: what they disagree about, in plain words.",
+  "type": "string"
+}
  2. Addedv2.1.0

TDQS

A4/5.0
Behavior5/5

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

Annotations only declare the generic safety profile (readOnly=false, destructive=false, idempotent=false), and the description adds genuinely non-obvious behavior: removes are soft-deleted and recoverable via manage_history undo, linked projects receive update todos and a 'changed since' line, and 'FlowState never edits other projects' — a strong side-effect boundary. It also states return shapes ('the link, the card, or {links}'), which nothing else provides since there is no output schema.

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 purpose and the action taxonomy are front-loaded, and the propagation/undo details are placed after the core definition, which is the right order. Dense fragmentary clauses ('depends on a project, two components are the same, records relate') compress well but cost some readability across 18 parameters.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a high-parameter, multi-action tool with no output schema, the description covers the missing pieces: per-action semantics, side effects on other projects, undo path, required project, and return types. Minor gaps remain around duplicate-link handling and failure modes, which matter given idempotentHint=false.

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 per-parameter baseline is 3, but the description adds real meaning by showing how parameters combine per action — e.g. link_type=uses with target_project/target_component for a component dependency, flag_conflict needing topic and evidence, and removal by either link_id or the original add fields. That combination logic is not expressible in a flat schema and materially helps invocation.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description opens with a specific framing ('Connect things across projects') and then enumerates its four operations and the link semantics they create (uses, depends_on, same_as, url, conflict flags). It clearly differentiates itself from log_work, manage_history, and list-style siblings by describing link creation/propagation rather than record logging. The phrasing is telegraphic ('two components are the same, records relate') so the resource is precise but not effortlessly parsed.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Usage is implied through the action breakdown: 'list: read-only', 'remove: by link_id or the add fields', and the note that log_work on a shared component drives propagation. However, there is no explicit statement of when to choose this tool over a sibling, no preconditions beyond 'Requires project', and no exclusions (e.g. when to avoid linking vs. using search/manage_projects). The agent must infer routing from the behavior spec.

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