DocumentationThe MCP server

Docs

The MCP server

What an assistant can do through the FEATit MCP server, its tools, and how to connect any MCP client to it, with the steps for Claude Code, Codex, OpenCode, Cursor, Claude Desktop, Claude and ChatGPT.

The FEATit MCP server gives an assistant the board as tools. Every deployment serves it at its own /mcp address. An assistant connects over the Model Context Protocol and signs in through your browser, so no token is copied into a file.

The tools

Through the MCP server an assistant can read and search items, file them, comment, move and close them, hand them to someone, manage releases, and create a work area once you confirm it. It holds the same permissions as the CLI, and a write it may not make comes back as an error that says why.

Each kind of thing has a tool that reads it and a tool that changes it, so your assistant can let reads through and ask you before a change. The action argument says what to do.

Tool Actions
featit_work_areas list the work areas this connection may read, and the namespaces it may see, with where it may create one. Read who is of an organisation as what, a Member, a Guest or a Public participant, with memberships, and the membership_types with what each allows. Read a work area’s guide for assistants and, with guide_history, one part’s history with who changed it and when, its rules in force (closing gates, admission, allowed moves), its challenge_points, its owner_flow settings, your agents, the fleet_pauses that hold them and their agent_limits (what each account has left of its usage-limit windows). export a whole work area as JSON, up to 5 MB, with the export permission, which an agent never holds. Read its statuses, its work_area_flow for an item type or an event flow, the types a new work area can be, the repositories it declares (repos) and those connected to it (streams), and its pages in order. Read its admission contract: the admission_vocabulary, the admission_contract in force, one admission_template with its skeleton, a dry admission_check of a draft, admission_stats on what the gate admitted and refused, and admission_changes, who changed the contract and what moved
featit_work_area_change create a work area, only after you confirm it in your assistant. invite a customer, tester or partner, who then reads only what is shared with their role. Set its service_levels, name its owner and who writes proposals with set_owner_flow, change an idea’s owner with a reason with change_idea_owner (what is open for the former owner on it moves too), and pause or resume a trust source with trust_source_status, giving a reason. These four need a Manager or Owner, and an agent pauses a trust source only where the Owner allows it. fleet_pause stops one agent, a person’s agents or a whole work area until a person resumes it with fleet_resume. An agent may pause, but never resume
featit_membership_change membership_type makes a person of an organisation a Member, a Guest or another type, or sets or clears the end of their membership. A lowering that would remove roles the new type cannot hold is refused, naming them, until you confirm removing exactly those. It needs the permission to manage memberships, which only a person holds
featit_items list items, filtered by type, state, search text or limit. show one by key, with its plan. next_up, comments, sync_status and holds. Read an item’s plan, the questions asked on it or across the work area, and its commits. Its history, its attachments (or the work area’s newest), and the work area’s recent_comments. Its context, everything an agent taking it needs in one answer, and its flow_history, why it went where it is. Its delivery_flow, where it stands on the delivery steps, each one lit only by what is recorded. The ideas you reported, an idea’s challenge and its proposal. What agents cost, for an item, a release or the work area, from your own prices, and the budget on an item or a release with how much of it is spent. Every item’s verification claims, read completely or reported as incomplete. An agent’s packet: the items it holds, what they wait on and the decisions blocking them. An item’s revision_sets, the exact file versions an approval covers. Who is told about an item’s changes (watchers), what each agent landed (commit_summary), the resolved items missing the commit their rules require (resolved_sha_audit), and the saved next-up queries (next_up_configs). Before filing a request, the expectations the work area has of its type: the clarity guide, the fields and the upload limits
featit_item_change Check a request for clarity with clarity: step ask asks at most three questions with suggested answers, and step brief restates the request. Then create it with the brief as its content and the message as written as its original, with the questions and answers beside it, and both are kept with the item. Put a token or money budget on an item or a release with set_budget. At 100 % starts on it are refused until its responsible raises it. Save a next-up query with next_up_config_save, make one the default with next_up_config_default and remove one with next_up_config_delete. Attach a file of up to 1 MB to an item with attachment_upload, or its next version with attachment_version, sent inline as base64 and stored as every upload is. For a larger file, send its size as sizeBytes instead: the answer is a short-lived upload address that takes that one file on that item, once. create an item, update its fields, parts or who is responsible, move it to a workflow state, transfer it to another work area, close it with a required note, reopen it, comment on it. confirm or decline what waits for a person, and reposition it. plan_start, plan_update and plan_supersede its plan. ask a question, answer one, or take it with question_claim. An agent’s question to a guest role waits as a draft until a member sends it with question_send. pin_comment or unpin_comment, and watch or unwatch an item. convert a task to an action and back, relate or unrelate two items, and merge a repeated request into the one it repeats. advance one branch of an item on parallel paths, though a step waiting for a person’s confirmation takes a person. Let it wait, postpone it or resume it. share it with guest roles, make the item its type makes from it (yours, on its part, implementing it), request_confirmation from its reporter, and check_report a build or test result. hand it to a cloud agent, or hand_off one step to a person. For an idea, challenge_save a challenge, challenge_answer its questions, save_proposal, put_to_owner, widen it to the full path or mark_larger_than_agreed. verify records what was verified and what it covers. freeze_revision freezes an item’s files as a revision set, and confirm_revision approves one exact revision by its digest, and confirm_revisions approves the current revision of several items at once. make_designs makes every design below a Job from its master picture, at each format’s size, starting from the direction the customer chose
featit_item_propose For a scheduled run that only reports: create an item, or comment on one. It cannot set a state, a responsible, parts, a release, a parent or a priority, and cannot close, move or reopen an item
featit_parts list a work area’s parts tree, to a depth, retired parts too if asked, and show one part by handle or id, with what changed since a date
featit_part_change create, update, move, split, merge, retire or delete a part, reopen a retired one, and relate or unrelate two parts. An item’s parts are set by updating the item
featit_schedules list a work area’s schedules, the regular work somebody expects and who answers for it, and show one with its newest runs, where it is adopted, and the prompt it holds by its sha256, never its text
featit_schedule_change create, update and retire a schedule, mute its watcher’s alerts for a while (a reason and an end date) and unmute them, set_prompt the prompt a harness schedule holds (answered by its sha256, never its text), tag it with the work area’s labels (the whole list, and a new tag only by an administrator), and check a run in with run_start and run_finish. A check-in carries a closed list of fields: no command, no output, no credential
featit_releases list a work area’s releases
featit_release_change create, update or delete a release (a delete must confirm it), and set an item’s release or take it out. ship it once, after which it never changes. backfill the releases done items shipped in
featit_decisions list a work area’s decisions, with their options and answers, and the decisions waiting for you in one work area, all you read or a whole namespace, oldest first, and the access_requests waiting for your answer beside them. revision_requested lists the decisions you asked whose responsible sent them back to you for a revision, with the feedback. Read its signed decision chain page by page, served as signed for you to verify with featit chain verify
featit_decision_change file a decision for a person or a named agent to answer, answer one that is yours or unanswer your answer. supersede, revise or withdraw one, claim it, or refuse it. request_revision sends a decision you are asked back to its asker with your feedback on what to change, before you answer. An agent never answers or claims a decision addressed to a person. unsupersede a supersede made by mistake, until the successor is answered, and postpone or resume one
featit_tasks list what waits for this connection’s person or agent: items they are responsible for, requests they may answer, and questions asked of them
featit_roadmap lanes: the roadmap explorer’s own lanes for a work area — periods, releases or topics grouped by part — the same reading featit roadmap and the web Roadmap’s Explorer layout give
featit_external_records list an item’s linked records (a GitLab or GitHub issue, a merge or pull request, or any page) with their status, and read one record’s conversation
featit_external_record_change link a record to an item or unlink it. comment on, close or reopen a linked record, sent once through its stream and labelled when an agent wrote it
featit_webhooks list a work area’s outbound webhooks and read one webhook’s deliveries. Read only: a webhook is set up by a person, in Settings or the CLI
featit_file_reviews repositories, list, show, messages, history, compare, capture
featit_file_review_change comment, propose, reply, edit, resolve, reopen, accept, reject, withdraw
featit_file_review_hand_on Hand saved review discussions to an agent as one item, a task linking every discussion and the version they are on
featit_artifact_shares policy, list, received, show, content, discussions, discussion, messages, history, snapshot_status
featit_artifact_share_change policy_update, create, update, revoke, resend, accept, prepare_snapshot, comment, propose, reply, edit, discussion_status, finalize_snapshot
featit_documents list the documents on a page, on an item, or in the whole work area, and show one with its markdown
featit_document_change save a new document on a page or an item, or new content for one. attach it to one more place, or detach it from one
featit_inbox list the notices addressed to this connection’s agent: mentions, replies, assignments
featit_inbox_change mark_read: mark every notice addressed to this connection read, so the next look shows only what is new. ack_instruction: acknowledge an instruction a FEATit schedule sent this connection’s agent, by its fireId, with done: true once it is done (only that agent can, a second ack answers “already”, and marking the inbox read does not acknowledge)
featit_access Read this agent’s own access requests with status, and the requests waiting for your answer where you may give access
featit_access_change request access to a work area as this agent, or withdraw a request still waiting. Where you may give access, approve or decline a request, and grant, extend or revoke an agent’s access. What needs your passkey or password answers with the page to confirm it on
featit_whoami show who this connection is: the agent and its owner, the work areas it may work in, and the kind of credential it holds
search Search items across every work area this connection may read (remote, for ChatGPT)
fetch Fetch one item in full, by an id search returned (remote, for ChatGPT)

Creating a work area asks you first. Your assistant shows the question, and nothing is created unless you confirm. An assistant that cannot ask is refused.

Connecting an assistant

In FEATit, open Connect an AI assistant — on the Agents page, or in Settings. It shows each assistant’s steps with your deployment’s address already in them, and a Cursor button and a Claude Desktop extension that need no typing. The address is:

On featit.com

https://featit.com/mcp

For Claude Code:

claude mcp add --transport http --scope user featit https://featit.com/mcp
claude mcp login featit

For Codex:

codex mcp add featit --url https://featit.com/mcp
codex mcp login featit

For OpenCode, add FEATit to ~/.config/opencode/opencode.json, then sign in with opencode mcp auth featit:

{
  "$schema": "https://opencode.ai/config.json",
  "mcp": {
    "featit": { "type": "remote", "url": "https://featit.com/mcp" }
  }
}

Claude (claude.ai, Claude Desktop, Claude for iOS) and ChatGPT add it as a custom connector. In Claude: Settings → Connectors → Add custom connector, with https://featit.com/mcp as its URL. In ChatGPT: turn on Developer mode under Settings → Apps & Connectors → Advanced, then create a connector with that URL and OAuth as its authentication. Either way, FEATit asks you to approve it.

On-premise

https://<your deployment>/mcp, which your assistant must be able to reach.

For Claude Code:

claude mcp add --transport http --scope user featit https://<your deployment>/mcp
claude mcp login featit

For Codex:

codex mcp add featit --url https://<your deployment>/mcp
codex mcp login featit

For OpenCode, add FEATit to ~/.config/opencode/opencode.json, then sign in with opencode mcp auth featit:

{
  "$schema": "https://opencode.ai/config.json",
  "mcp": {
    "featit": { "type": "remote", "url": "https://<your deployment>/mcp" }
  }
}

Claude and ChatGPT connect from their makers’ servers, not from your computer, so their custom connectors reach only a deployment with a public address. Behind a firewall or on a private network, use the assistants above, which connect from the computer they run on.

A runner that only starts local servers

For a runner that cannot connect to an address, FEATit also comes as a local server that speaks MCP over standard input and output. From the code/ directory of a FEATit checkout, after yarn install:

yarn workspace @featit/mcp build

That writes the server to code/mcp/dist/server.js. It reads its settings from the environment:

Variable What it is
FEATIT_API_URL Your deployment’s API address, ending in /api
FEATIT_ACCESS_TOKEN The agent’s access token. Its writes are recorded as that agent
FEATIT_WORK_AREA_ID Optional: the work area to use when a tool call does not name one

For a runner that reads an mcpServers block:

On featit.com

{
  "mcpServers": {
    "featit": {
      "command": "node",
      "args": ["<checkout>/code/mcp/dist/server.js"],
      "env": {
        "FEATIT_API_URL": "https://featit.com/api",
        "FEATIT_ACCESS_TOKEN": "<your access token>"
      }
    }
  }
}

On-premise

{
  "mcpServers": {
    "featit": {
      "command": "node",
      "args": ["<checkout>/code/mcp/dist/server.js"],
      "env": {
        "FEATIT_API_URL": "https://<your deployment>/api",
        "FEATIT_ACCESS_TOKEN": "<your access token>"
      }
    }
  }
}

The token sits in that file in plain text, so anyone who can read the file can act as this agent. Prefer the address above wherever the runner can use it.

Use an agent’s token here, not your own. With a person’s token the server still reads, but it refuses every write that names no agent, so that nothing an assistant does is recorded as yours. The one exception is answering a move held for you.

MCP or the CLI?

Both reach the same API and the same items, with the same permissions. The MCP server covers the work an assistant does in a conversation: items, their plans, questions, comments and history, watching and the inbox, documents, commits, decisions, releases, the roadmap and work areas. The CLI is the whole surface — admission checks, agents and the rest — and it is what the agent skill teaches an agent to use.

NextCapabilities