MCP · For coding agents

Connect your agent to featury

featury exposes a remote MCP endpoint so coding agents (Claude Code, Kimi CLI, Cursor, any MCP client) can work with your workspace: triage requests, read the feature inventory, see what shipped, and ask the codebase agent questions.

Quickest: install the plugin

Using Claude Code or Codex? The featury plugin does steps 1, 2 and 5 below for you: it connects your agent to featury and adds the skill. There's no key to copy.

Claude Code

claude plugin marketplace add owe-br/plugins
claude plugin install featury@owe-br

Codex

codex plugin marketplace add owe-br/plugins
codex plugin add featury@owe-br
codex mcp login featury

In Codex, the last line signs you in. In Claude Code, type /mcp, pick featury and choose Authenticate. Your browser opens featury, and you press Connect.

See the plugin on GitHub

1. Create an API key

In the app, go to Account → API keys → Create API key. The full key is shown only once. Store it somewhere safe. Only its hash is kept server-side, so it can't be recovered later.

A key acts as you: the agent works with your identity and your exact permissions in every workspace you belong to, no more, no less. Revoke a key from the same page the moment it leaks.

Open Account settings

2. Connect your agent

Point your MCP client at the endpoint below, with your key as a Bearer token. Transport: Streamable HTTP (stateless).

https://api.featury.app/mcp

claude.ai, ChatGPT and other apps that sign in

Add featury as a connector with the address above and no key. The app opens featury, you press Connect, and that's it. It gets its own key, listed under Account → API keys, where you can revoke it.

An agent on a machine with no browser (a server, a container) can sign in with a short code instead of a pasted key. The featury skill below teaches it how.

Claude Code

claude mcp add --transport http featury https://api.featury.app/mcp \
  --header "Authorization: Bearer fk_…" \
  --header "X-Featury-Agent: claude-code"

Codex

# ~/.codex/config.toml
[mcp_servers.featury]
url = "https://api.featury.app/mcp"
bearer_token_env_var = "FEATURY_API_KEY"
http_headers = { "X-Featury-Agent" = "codex" }

Goes in ~/.codex/config.toml. Export FEATURY_API_KEY=fk_… in your shell. Codex reads the token from the environment instead of the file.

Cursor, VS Code, and other MCP clients

Most clients take a JSON block like this: the endpoint URL plus an Authorization: Bearer fk_… header, Streamable HTTP transport. Self-hosted? Use your own API origin instead.

{
  "mcpServers": {
    "featury": {
      "url": "https://api.featury.app/mcp",
      "headers": {
        "Authorization": "Bearer fk_…",
        "X-Featury-Agent": "claude-code"
      }
    }
  }
}

3. Who did what

Every action your agent takes lands under your account. Featury can also show WHICH agent did it: “Claude Code · via you” on timelines, comments and the board.

Bind an agent to the key at mint time (Account → API keys → Create API key → “Acts as”): every call made with that key is attributed to that agent, with no client configuration needed. This is the recommended setup.

Prefer per-request control? Have each client send an X-Featury-Agent header, as in the snippets above. An explicit header overrides the key's binding, so one shared key can serve several agents.

And if neither is set, featury falls back to the name the client reports when it connects (“claude-code”, “cursor”). Attribution works even with zero configuration.

4. What your agent can do

Discovery tools (list_workspaces, list_projects) find the workspace and project slugs for you; every other tool takes them: the same slugs you see in the app's URLs.

Tool	What it does
list_workspaces	The workspaces you belong to (id, name, slug, your role): the discovery entry point
list_projects	The projects you can access in a workspace (id, name, slug, access mode)
get_product_overview	What the product is, synthesized from its code: headline, pitch, what it does
list_requests	List requests (bugs + feature asks), filterable by status, kind, horizon, size, impact, search. Compact rows sized for board grooming, with updatedAt, shippedAt and area (detail: "full" for the complete objects)
get_request	Full request detail: journey, comments, spec artifacts, reality read
create_request	File a new request (standard triage: dedup, area resolution, reality read)
update_request	Groom a request: pin a human horizon/size/fit override and/or edit title/body/severity (same paths as the in-app actions)
set_request_status	Move a request through the manual lanes: OPEN / PLANNED / CLOSED / DECLINED
add_request_comment	Comment on a request (notifies participants, @Name mentions ping)
merge_requests	Absorb a request into another (duplicates): the child ships automatically when the parent does
list_features	The project's living feature inventory
get_feature	One feature in full: where it lives in the code, what changed it, and who knows it
list_areas	The product areas the feature map is clustered into
list_decisions	The recorded decisions: ADR-light project memory for what does NOT live in the repo
read_decision	Full detail of one decision: its context, what was decided, and its lifecycle status
create_decision	Record a decided call as durable project memory (MANAGER+)
update_decision	Edit a decision's wording or move its lifecycle along (MANAGER+)
recent_changes	Recent classified changes: what shipped, in plain language
list_in_flight	What's being built right now: open pull requests and release lanes, mapped to the product
get_changelog	The changelog in one read: the public page, the rhythm, the writer's notes, and the edition under review
set_changelog_notes	Rewrite the standing notes that steer what the changelog tells and how (MANAGER+)
set_changelog_cadence	Set how often an edition is drafted, and how long it waits before publishing itself (MANAGER+)
prepare_changelog_edition	Draft the next edition now, replacing any open draft (MANAGER+)
update_changelog_edition	Edit the draft before it goes out: rename it, reword, reorder or drop entries (MANAGER+)
publish_changelog_edition	Publish the draft. It gets its number and permalink, and the public page goes live (MANAGER+)
unpublish_changelog_edition	Take the most recent edition back to being the draft (MANAGER+)
ask_featury	Ask the codebase agent a question; pass conversationId to continue a thread
create_report_schedule	Schedule a recurring summary Update for a project: every intervalDays (optionally pinned to a weekday), at hour:minute UTC
list_report_schedules	The project's recurring summary schedules (cadence, UTC slot, last/next run)
delete_report_schedule	Delete a recurring summary schedule. Generated Updates are kept, future runs stop
list_webhook_endpoints	The project's outbound webhook endpoints (MANAGER+, like all webhook tools)
create_webhook_endpoint	Register an endpoint for signed product events. Returns the signing secret exactly once
update_webhook_endpoint	Change an endpoint's url, label, events, or enabled state (enabled: true revives an auto-disabled one)
delete_webhook_endpoint	Delete an endpoint and its delivery history
rotate_webhook_secret	Mint a fresh signing secret: the old one stops immediately, the new one is shown once
test_webhook_endpoint	Send a signed test ping synchronously and report the outcome
list_webhook_deliveries	An endpoint's recent deliveries: status, attempts, HTTP code, error
get_webhook_delivery	One delivery with the exact JSON payload that was sent

5. Optional: teach it the workflows

The featury skill teaches your agent when to use which tool, how to triage requests and how to report what it found back onto them. The plugin above already includes it. Without the plugin, put it in your agent's skills folder:

mkdir -p ~/.agents/skills/featury \
  && curl -fsSL https://featury.app/skill/featury/SKILL.md \
  -o ~/.agents/skills/featury/SKILL.md

Any skills directory your agent reads works (e.g. ~/.claude/skills/featury/ for Claude Code). View the skill file

Good to know

BUILDING and SHIPPED are derived from real code signals and can never be set by hand. Same rule as in the app.
One signal you control: cite a request's refCode in a commit or PR message ("Closes idea/dark-mode", "Fixes bug/login-white-screen") and the ticket auto-ships and notifies its requester.
Mutations behave exactly like the in-app actions (journey events, notifications) and are attributed to you.
ask_featury spends the workspace AI budget, like a chat message in the app.
Errors come back with a human-readable message (e.g. "Workspace not found"). Never stack traces.
Prefer plain HTTP? Every MCP capability is also available over a versioned REST API. Same keys, same permissions. API docs →