MCP-инструменты

Create a new project inside an organization. Returns the created project node with its ID and slug.

org_idnamekeyspec

Idempotent bootstrap: ensure an organization and project exist, creating them if absent. Use this at the start of an agent session to set up the workspace. Returns org_id, project_id, flags indicating whether each was newly created, and spec_mode — the project's spec policy (off|strict). In strict mode closing a task requires an applied spec delta or an explicit declare_spec_impact; write spec_mode into .ai-flow so later sessions know the rules before writing code.

org_nameproject_nameproject_keyproject_spec

List all organizations the authenticated user belongs to. Returns org IDs and names. Call this first to discover available org_ids.

List all projects in an organization. Returns id, slug, name, and spec for each project.

org_id

Permanently delete a node and all its children. This action is irreversible. Provide either node_id or slug+project_id.

node_idslugproject_id

Get a node by ID or slug. Returns full detail: title, content, status, progress, tags, comments, dependencies, references, and child_ids. Provide either node_id alone, or slug+project_id.

node_idslugproject_id

Get a node by its slug. Returns full detail including child_ids. Equivalent to get_node with a slug.

slugproject_idnode_id

Get the full hierarchy tree of a project: epics → features → plans → tasks. Use this to understand the overall project structure before drilling into nodes.

project_id

List nodes in a project. Filter by kind (epic/feature/plan/task/doc) and/or parent. Returns id, slug, title, kind, status, progress for each node.

project_idkindparent_idparent_slugticket_refcomponent

Move a node to a new parent. Provide node_id or slug, and new_parent_id or new_parent_slug. Nodes are sorted by creation time automatically. The spec_first decomposition gate applies here too: moving a task or plan under a feature that has no approved delta is refused exactly as creating one there would be. The gate stands on both paths on purpose — otherwise it would be bypassed in two calls.

node_idslugproject_idnew_parent_idnew_parent_slug

Update the title and/or Markdown body of an epic, feature, plan, or task node.

node_idslugproject_idtitlecontentcommit_hashticket_ref

Update the completion percentage of a node. Progress is an integer from 0 (not started) to 100 (complete).

node_idslugproject_idprogress

Change the status of a node. Use this to mark tasks as in-progress, done, blocked, etc.

node_idslugproject_idstatus

Create a dependency edge: from_node depends on to_node. to_node is the blocker and must be completed before from_node can start. Read it as the sentence "from_node depends on to_node". Provide IDs or slugs for each node.

from_nodefrom_slugto_nodeto_slugproject_id

Add a typed bidirectional relation between two nodes. Automatically creates the inverse relation.

from_nodefrom_slugto_nodeto_slugproject_idrelation_type

Add a label/tag to a node (e.g. 'backend', 'frontend', 'urgent', 'domain'). Tags are used for filtering and categorization.

node_idslugproject_idtag

Get both sides of the dependency graph for a node: depends_on (blockers this node waits for) and blocks (nodes waiting for this one).

node_idslugproject_id

Get all cross-references for a node: nodes this node references (outgoing) and nodes that reference it (back-references).

node_idslugproject_id

Get all typed semantic relations for a node (e.g. blocks, blocked_by, related_to, depends_on). Returns both outgoing and incoming relations.

node_idslugproject_id

Remove the dependency edge "from_node depends on to_node". Same direction as add_dependency.

from_nodefrom_slugto_nodeto_slugproject_id

Remove a typed relation between two nodes. Also removes the inverse relation.

from_nodefrom_slugto_nodeto_slugproject_idrelation_type

Set cross-references on a node (overwrites existing). Identify the node by slug or node_id, and the references by ref_slugs (JSON array of slugs) and/or ref_ids (JSON array of node IDs). Slugs are enough on their own — project_id is optional, and a ref_slug may point at a node in another project.

node_idslugproject_idref_idsref_slugsnode_idslugproject_id

Create a documentation node (wiki page) inside a project. A doc that describes system behaviour is a spec: write it in the OpenSpec format — `## Purpose`, then `### Requirement: <name>` with a RFC 2119 keyword (SHALL/MUST/SHOULD/MAY), then `#### Scenario: <name>` with `- GIVEN` / `- WHEN` / `- THEN` steps. That format is the only accepted way to record behaviour: freeform prose describing a contract is a defect, validate_spec reports it, and in spec_mode=strict a delta that adds a new violation is refused.

org_idproject_idtitlecontentcomponentsspec_domain

List a project's archived documentation nodes, most recently archived first. This is the only place archived docs are visible: list_docs and get_tree do not show them. If a doc you expected is missing from list_docs, look here before concluding it was deleted.

project_id

List all documentation nodes (wiki pages) in a project. Archived docs are NOT included — a doc missing from this list may be in the archive rather than deleted; use list_archived_docs to check.

project_idcomponent

Restore an archived documentation node: it returns to the tree, to list_docs and is queued for reindexing. Restores ONE doc, not a subtree — archiving cascades, restoring does not. If the doc's parent is still archived the doc moves to the project's docs root, and the response says so via reparented_to_root: tell the user, otherwise they will look for the doc where they left it. Use list_archived_docs to find what can be restored.

doc_iddoc_slugproject_id

Update the title and/or Markdown content of a documentation node.

node_idslugproject_idtitlecontentspec_domain

HUMANS ONLY — you cannot call this. Approving a proposed spec delta is the user's decision, and a call from an agent session is refused with PermissionDenied. This tool is listed so you know the name of the step you are waiting on: when a delta is pending review, stop, tell the user the delta is waiting for approval, and name it. Do not re-propose the delta, do not apply it, do not move the task into in_progress — none of that will work until the user approves it in the web UI. Resume only after list_doc_deltas shows review_status: approved.

revision_idnote

Declare that a node changes no documented behaviour, so no spec delta is needed. What it unblocks depends on the node kind, and these are NOT the same permission. On a task or plan it lifts the CLOSING gate: in spec_mode=strict this is the only way to reach done without an applied delta. On a feature it lifts the DECOMPOSITION gate: with spec_first on, you may create tasks under that feature without driving its document to approval. A declaration on a feature does NOT cascade down: every task under it still answers for its own spec, and closing each one still needs its own delta or its own declaration. Do not declare on the feature hoping to free the whole subtree — the closing gate reads the declaration of the node it is closing and nobody else's. reason must be a sentence naming what you changed and why it touches no documented behaviour — "n/a", "none" or a single word is rejected. If you cannot write that sentence, the change probably does affect the spec: propose a delta instead.

node_idslugproject_idreason

Remove a delta from the doc's history entirely — no row is left behind. This is for garbage: a duplicate, a proposal made by mistake, a delta nobody will ever read. It is NOT the normal way to reject a delta: use discard_doc_delta for that, which records that the proposal was considered and rejected. Choose by intent, not by force: discard = "we decided against this", delete = "this should never have been here". Works only on proposed and discarded deltas. An applied delta cannot be deleted — it is spec history, and both the diff against the neighbouring version and reading the doc at that version rest on it; if an applied change is no longer right, propose a new delta instead.

revision_id

Record the decision that a proposed delta will not be applied. The delta stays in the doc's history as discarded — anyone reading it later can see the proposal was considered and rejected. This is the normal way to say no to a delta. Use delete_doc_delta only when there should be no row at all (garbage, a duplicate, an accidental proposal). Only works on proposed deltas: an applied delta is history and is not rolled back — propose a new delta instead.

revision_idreason

Export the project as an OpenSpec directory tree and get back the list of files to write. Call this when the project's specs should live in the repository next to the code. Returns files[] with a path (starting with openspec/) and content for each — WRITE THEM YOURSELF with your file tools, relative to the repository root. This server does not touch your disk: it runs over HTTP for everyone at once, so a path it wrote to would be someone else's machine. The tree holds specs/<domain>/spec.md per document, changes/<slug>/ per open feature (proposal.md, design.md, tasks.md, delta specs) and changes/archive/<date>-<slug>/ per closed one.

project_id

Read one spec delta in full, including its round history: every review round with the action (submitted/approved/rejected/reopened), who did it, when, the reason, and the delta body AS IT WAS at that moment. That last part is the point — after a rejected draft has been reworked, the rejected text exists nowhere else, and "what did we throw away and why" is the question the history answers. list_doc_deltas does not return rounds: each round carries a whole document body, and in a list the history would outweigh the deltas themselves.

revision_id

Read the project's spec policy before doing work. In spec_mode=strict, closing a task requires either an applied spec delta (propose_doc_delta then apply_doc_delta) or an explicit declaration that the spec did not change (declare_spec_impact: none) — otherwise the close is rejected. Call this when .ai-flow is missing or may be stale (the mode can be switched on after init). In strict mode a delta must also not make the document's OpenSpec format worse than it was: spec documents are written as `## Purpose` / `### Requirement: <name>` (SHALL/MUST) / `#### Scenario: <name>` (GIVEN/WHEN/THEN), and validate_spec tells you where you stand. The answer also carries spec_first and spec_first_requirement: with spec_first on the ORDER OF WORK is reversed — the feature's document is written and approved BEFORE any task is created under it, and creating one earlier is refused. Read that field before decomposing anything.

project_id

Load an OpenSpec directory tree into the project. Call this when a project is set up on top of a repository that already has openspec/. READ the tree yourself first with your file tools — every openspec/**/*.md — and pass the files here with their paths relative to the repository root. Idempotent by spec domain and by the changes/<name> directory: running it again on an unchanged tree creates nothing and proposes no deltas, so it is safe to call after every pull. Returns which nodes were created, updated and left alone, plus the ids of any deltas it proposed.

project_idfilesitemspropertiespathcontent

List spec deltas: history of one doc (doc_id/doc_slug), deltas produced by one task (source_node_id/source_node_slug), or every delta still waiting to be applied in the project (project_id). Filter by state: proposed|applied|discarded. Each delta also carries review_status (draft|pending|approved|rejected) with reviewed_by/reviewed_at/review_note — that is the human decision on the proposal, separate from state. draft means nobody has been asked yet. On a project with require_proposal_approval this is how you check whether you may start: read it before moving a task into in_progress and before apply_doc_delta. Filter by review_status to find your own drafts. Round history is NOT returned here — use get_doc_delta for one delta when you need it.

doc_iddoc_slugproject_idsource_node_idsource_node_slugstatereview_status

Propose a new state of a spec document (doc node) as a delta tied to the task that caused the change. body MUST be the FULL new document body — the complete Markdown of the doc after your change, not a patch, not a diff, not just the changed section. Applying a delta replaces the document body wholesale, so a fragment silently collapses the spec to that fragment. Read the doc first (get_node), edit the whole text, send it back. In spec_mode=strict this is how a task earns the right to be closed. A spec document is written in the OpenSpec format: `## Purpose`, then `## Requirements`, then one `### Requirement: <name>` per behaviour with a RFC 2119 keyword (SHALL/MUST/SHOULD/MAY) in its text, each followed by `#### Scenario: <name>` with `- GIVEN` / `- WHEN` / `- THEN` steps. The response carries spec_issues — what is still off about the format — and ops, the requirements this delta adds, changes, removes or renames. In spec_mode=strict a delta that introduces issues the previous version did not have is rejected; issues inherited from the previous version do not block. Run validate_spec on your draft first to avoid that round trip. The delta comes back with review_status: pending. On a project with require_proposal_approval this means STOP: tell the user the proposal is waiting for approval and name it, then wait. Until review_status is approved you may not apply the delta and may not move the covered task into in_progress — both calls are refused. EXCEPTION on a project with spec_first on: the delta is born review_status: draft, which asks nobody anything. A draft is your working copy — keep editing it with update_doc_delta, and it reaches the human only when you call submit_doc_delta. Do not tell the user a draft is waiting for their approval: it is not, and they will be waiting for each other.

doc_iddoc_slugproject_idsource_node_idsource_node_slugtitlebodyreason

HUMANS ONLY — you cannot call this, same as approve_doc_delta. Rejecting a proposed spec delta is the user's decision and a call from an agent session is refused with PermissionDenied. If the user tells you a delta was rejected, read its review_note, rebuild the spec accordingly and propose a new delta — a rejected delta can be approved later, so do not delete it to start over.

revision_idreason

Set the project's spec policy. spec_mode=strict makes every task close require either an applied spec delta (propose_doc_delta then apply_doc_delta) or an explicit declare_no_spec_impact — a project with no spec documents will have its very next task blocked by that gate, so bootstrap the spec first. spec_mode=off removes the requirement. Only a member of the project's organization may change this. Ask the user before switching the mode; never do it silently. require_proposal_approval adds the OpenSpec approval gate: a proposed delta must be approved by a human before the covered task may enter in_progress and before the delta may be applied. Omit the field to leave it as it is. spec_first reverses the order of work: the delta is born a draft, and creating a task or plan under a feature is refused until that feature has an approved delta. It only makes sense together with spec_mode=strict and require_proposal_approval — turning it on without them is refused with InvalidArgument, and so is turning either of them off while it is on. Enabling all three in one call is the normal way to switch a project over. Returns the settings as stored by the server — write those into .ai-flow, not what you asked for.

project_idspec_moderequire_proposal_approvalspec_first

Send a draft delta to the human for review: review_status goes draft → pending. This is the only way a draft becomes a question addressed to somebody. What changes the moment you call it: the delta appears in the review queue, it starts holding the gates (the covered task can no longer enter in_progress, the delta can no longer be applied), and it can no longer be edited in place until a human decides. So after calling it, STOP. Tell the user which delta and which document are waiting for them, and wait — you cannot approve it yourself, and re-proposing, re-submitting or deleting it does not move anything forward. Refused with FailedPrecondition if the delta is not a draft, and refused if the draft made the document's OpenSpec format worse than its base — spending a review round on something the server already knows is wasteful.

revision_idnote

Edit a delta in place instead of proposing a new one. Works only on a delta whose review_status is draft or rejected; an approved one is refused, because approval refers to the text the human actually read — change that with a NEW delta, not by rewriting what they signed off. Editing a rejected delta returns it to draft and records a round, so the rejected body and the reason stay readable afterwards. body MUST be the FULL new document body, exactly as in propose_doc_delta — the complete Markdown after your change, not a patch and not just the paragraph you fixed. Applying a delta replaces the document wholesale, so a fragment silently collapses the spec to that fragment. The temptation is stronger here than when proposing, because "update" sounds like it should take a piece: it does not. Format issues come back in spec_issues but do NOT block the edit — a draft is written in passes, and a ratchet here would make it impossible to save a requirement before its scenario is written. The ratchet applies at submit_doc_delta.

revision_idtitlebodyreason

Check whether a spec document follows the format, and get back what to fix. Changes nothing. A spec document is written in the OpenSpec format: `## Purpose`, then `## Requirements`, then one `### Requirement: <name>` per behaviour with a RFC 2119 keyword (SHALL/MUST/SHOULD/MAY) in its text, each followed by `#### Scenario: <name>` with `- GIVEN` / `- WHEN` / `- THEN` steps. Pass doc_slug (or doc_id) to check a saved document, or body to check text you have not saved anywhere yet — use the second form BEFORE propose_doc_delta so you learn about a problem while you still have the spec in your head. Each issue names a machine code, the place in the document, and what to do about it.

doc_slugdoc_idproject_idbody

Create a new code review with its first iteration. Returns the review with iterations.

project_idreviewerbranchcommit_hashcontentcomponents

Get all reviews that are linked to a specific node. Use this to see which code reviews reference a given task or feature.

node_idslugproject_id

Get a review with all its iterations.

review_id

List all reviews for a project.

project_idcomponent

Replace the set of components a code review is linked to. The set is replaced whole; an empty list unlinks everything.

review_idproject_idcomponents

Link a review to one or more nodes (overwrites existing links). Creates a bidirectional navigable link: the review shows the nodes as chips, and each node shows the review as a backlink. Pass the full desired list of node_ids — this replaces all existing links.

review_idnode_ids

Get one system component in full: description, progress, child components, and EVERYTHING linked to it — tasks and features, documents, and reviews. Do not collect those with separate calls; this one returns them.

componentproject_id

List the system components of a project, flat, with parent_id and PROGRESS for each: percent, total, done, a breakdown by status, and counts of linked docs and reviews. Progress covers work linked to the component or to any component below it in the tree — so this one call answers "how is gateway doing" without counting tasks by hand.

project_idcomponent_kindlifecycle

Replace the set of components a node (task, feature, doc, ...) is linked to. The set is replaced WHOLE: pass an empty list to unlink everything. A node can belong to several components.

nodeproject_idcomponents

Update a system component. Only the fields you pass are changed; omitted fields keep their current values.

componentproject_idtitledescriptioncomponent_kindrepo_pathlifecycleparent

Semantic (RAG) search over a project's indexed nodes and comments. Returns ranked chunks by meaning, not exact text — use this to find relevant tasks/docs by concept. This is distinct from list_nodes/get_tree, which browse the project structure by hierarchy and exact filters. Results below a relevance floor are dropped, so an EMPTY result with filtered_out > 0 means nothing in the project answers this query — treat that as a real answer, not as a reason to reason from weak matches. Content is returned as a snippet; open a hit with get_node before relying on its details. Read-only; does not modify the index.

project_idquerykkind_filterstatus_filteritemscomponentmin_scoremax_content_chars

Report the RAG index status for a project: total indexed chunks, per-status node counts, vector dimension, and the sync-status breakdown (pending/in_progress/synced/failed). Use this to check whether the semantic index is up to date before relying on rag_query/rag_context. Read-only.

project_id

List all available Flownix agent skills with their slug, name, description, and MD5 hash. Does NOT return content — use get_skill to fetch content for a specific skill only when its MD5 differs from the local copy. Also returns `retired`: slugs that are no longer served (renamed or removed) and must be deleted locally.

Optional. Tell Flownix who and where you are, so the agent presence panel can show your session properly. Call it ONCE at the start of your work; calling it again is harmless. Everything else about your session (that you are connected, which task you are on, how many calls you made) is already tracked automatically — this call only adds what the server cannot know. Omit any field you cannot determine; an omitted field never overwrites what is already known.

agent_nameai_modelhostoscwdgit_branch

Optional. Close your presence session immediately when you finish working. Without it the session is closed automatically once it stops making calls, so this only makes the presence panel accurate sooner.

reason

Optional. Report token usage and cost for this session. Values are CUMULATIVE SINCE THE START OF THE SESSION, not deltas since the last report: a skipped report must not make the total drift. Usually called by the optional statusLine reporter script rather than by the agent directly. When nothing reports usage, Flownix shows 'not reported' rather than zero — so never send a made-up zero.

input_tokensoutput_tokenscost_usd

Add a node to the harness workflow graph. Each node represents a step in the execution — an agent task, review, vote, condition gate, or loop. Connect nodes with harness.connect_workflow_nodes to define execution flow. Returns the created node with its ID.

harness_version_idtypenameconfiginput_bindingsoutput_bindingstimeout_secondsretry_policy

Clone an existing harness definition with a new name. Creates a deep copy of the harness including all roles, workflow nodes, edges, and policies. The cloned harness starts as a draft with version 1. Useful for creating variations of existing harnesses.

harness_idnew_name

Connect two workflow nodes with a directed edge. Defines the execution flow: the source node runs first, then the target node. For conditional branching, add a condition to the edge. Multiple edges from the same node create fan-out (parallel or conditional).

harness_version_idfrom_node_idto_node_idconditionprioritymapping

Create a new harness definition — a reusable multi-agent workflow template (e.g. council, review board, debate). Returns the created harness with its ID. After creation, add roles and workflow nodes with harness.add_role and harness.add_workflow_node.

workspace_idnamedescriptiontype

Create a new version of a harness definition. Each version snapshots the workflow graph, input/output schemas, policies, and budget. The new version starts as a draft — use harness.publish to make it the active version. Version numbers are sequential (1, 2, 3…).

harness_idchangeloggraph_definitioninput_schemaoutput_schema

Export a harness as a downloadable ZIP archive. The archive contains: harness.yaml (metadata), roles.md (all role descriptions), rules.yaml (policies), workflow.json (graph definition), system-prompts/*.md (per-role system prompts), and README.md (usage instructions). Returns a temporary download URL (expires in 1 hour).

harness_idversion_id

Get a harness definition by ID. Returns the harness metadata (name, type, status) and all its version details including graph definition, roles, policies, and budget. Use this to inspect a harness before editing or running it.

harness_id

Publish a harness version — makes it the current active version and sets the harness status to 'published'. Only draft versions can be published. The harness must be valid (pass harness.validate) before publishing. Returns the published version.

harness_version_id

Set a policy on a harness version. Policies control what agents can do: which tools they use, what data they access, how voting works, budget limits, and approval requirements. Multiple policies can coexist — deny overrides allow, require_approval adds a gate.

harness_version_idcategoryeffectsubjectactionresource_patterncondition

Start a run of a published harness version. Creates the run and immediately advances it: the graph's start node(s) get a step_run, and node types that need an agent (agent_task, review, debate, vote, judge, human_gate, loop) get a work item — visible right away via work.list_available(run_id, role_key). Returns the created run.

workspace_idharness_idharness_version_idtitleinputsource_node_ids

Update an existing agent role. Only the fields you provide are changed — omitted fields keep their current values. Use this to refine system instructions, adjust instance counts, or update responsibilities without recreating the role.

role_idnamedescriptionobjectivesystem_instructionsresponsibilitiesprohibited_actionsoutput_schemamin_instancesmax_instances

Validate a harness version before publishing. Checks for: missing roles referenced by workflow nodes, disconnected nodes (no path from start to end), circular edges, unfulfilled role bindings, and policy conflicts. Returns a list of errors (must fix) and warnings (should fix).

harness_version_id

Mark a work item as completed. Releases the lease and records the result artifacts. The run orchestrator will advance to the next step. Call this only after you've finished processing and have produced the expected output.

work_item_idresult_artifact_ids

Mark a work item as failed. The failure spends one attempt out of max_attempts: while attempts remain the item goes back on the queue for another agent and the step stays alive. Once attempts run out — or when you pass no_retry — the step fails and the run is marked failed.

work_item_iderror_messageno_retry

Extend the lease on a claimed work item. Call this periodically (e.g. every 30 seconds) while processing a work item. If the lease expires before you call work.complete, the item becomes available to other agents. Returns the updated lease expiry.

work_item_id

List available (unclaimed) work items for a run. Each work item represents a step that needs an agent. Filter by role to find items matching your agent's capabilities. Returns items with their input artifacts and deadline.

run_idrole_key

Attach evidence to a claim. Evidence provides support, contradiction, or context for claims. Use this to back up facts with code references, documents, test results, or external URLs. Returns the evidence link with its relation to the claim.

claim_idtypeuricontent_snapshotmetadata

Cast a vote on a ballot. Each agent can vote once per ballot. The ballot's method determines how votes are interpreted: single_choice (pick one), approval (pick all you support), ranked_choice (rank options), score (rate each). Returns the recorded vote.

ballot_idagent_idoption_idscorerankrationale_summaryconfidence

Respond to a critique on your proposal or claim. You can accept the critique (agree with the issue), partially accept, reject it, revise the original proposal, or request more evidence. This drives the iterative review cycle.

critique_idauthor_agent_idbodyaction

Revise an existing proposal based on feedback. Creates a new proposal version that supersedes the original. The revised proposal inherits the original's claims unless explicitly changed. Use this after accepting critiques to address their concerns.

proposal_idtitlesummarybodyconfidence

Submit a claim attached to a proposal. Claims are factual assertions, assumptions, predictions, or risks that support or qualify the proposal. Each claim can have evidence attached and may be verified or contradicted. Returns the created claim.

proposal_idtexttypeconfidence

Submit a critique on a proposal, claim, or another critique. Critiques identify issues (correctness, security, feasibility, etc.) and drive the review cycle. Each critique should suggest a resolution. Severity levels: info (FYI), minor (should fix), major (must fix), blocking (prevents approval).

deliberation_idauthor_agent_idtarget_typetarget_idcategoryseveritysummarybody

Submit a final judgement as a judge agent. Unlike voting (which uses ballots), judgements are authoritative decisions made by a designated judge role. Selects winning proposals, produces a decision with rationale, and may request user approval. Returns the decision.

deliberation_idauthor_agent_idselected_proposal_idssummaryrationaleconfidence

Submit a proposal to a deliberation. Proposals are the primary output of council agents — they propose solutions, approaches, or decisions. Each proposal can have claims attached and may be critiqued by other agents. Returns the created proposal.

deliberation_idauthor_agent_idtitlesummarybodyconfidence