Trail
dev.usetrailPublished by usetrail.devv1.29.1Updated Oct 25, 2026
Issue tracker and durable project memory for your coding agent, scoped to the folder you open.
Overview
Trail connects a coding agent to your team's issue tracker and durable project memory, scoped to the folder you have open.
- What you can do
- List, read, create, update, move, pick up and delete tracker items with type, status, priority, assignees and history, and fetch the next item to work on, plus add and read item attachments. Read, add, update and review durable project memory shared by everyone on the project. Add, list, update and delete dated reminders, closing or rescheduling them when the date arrives. Optionally install a session-start hook so open items and project memory are in context from the first message.
- When to use it
- Useful when a coding agent should work from a real team board instead of a scratch file: picking up open items, recording what it did, and keeping hard-won project knowledge that later sessions can read before acting.
- Requirements
- Node 18 or newer, run locally over stdio. A Trail account (free plan covers three projects and three people) and a browser login that saves a token to a local config file. Optional variables: TRAIL_API_URL for a self-hosted Trail, TRAIL_PROJECT to force the project name, TRAIL_API_TOKEN to skip browser login (for example in CI), TRAIL_LANG for console language. Network access to the Trail API.
Installation
In SourceWeft
- Open Trail in the dashboard and add it to a workspace.
- Enable the server for the chats that should use its tools.
Desktop only via STDIO. STDIO servers start a local process, so they need the SourceWeft desktop host.
Other MCP clients
Follow the launch instructions in the repository.
README
usetrail
The MCP server for Trail - it gives your coding agent your team's tracker and the project's durable memory, scoped to the folder you have open.
Your agent stops working blind. It reads what is open, writes what it did, and records what it learned the hard way - in the same board your team looks at, not in a scratch file that only that session can see.
This package is the client. It talks to your Trail account over the REST API; there is no
database here. Dependencies are @modelcontextprotocol/sdk, zod and the built-in fetch.
Quick start
No account yet? Create one at usetrail.dev - the free plan covers three projects and three people.
Not tied to one agent. This is a plain MCP server over stdio, speaking the three protocol versions in use today. Any MCP-compatible client can run it; only the registration command differs, and each client documents its own.
Prefer a local checkout? Clone it instead, and the connector keeps itself up to date on its own (see Updating):
On Windows, write the real path instead of ~: the registration stores the argument verbatim
and Node does not expand it.
What your agent gets
The tracker - list_items, get_item, add_item, update_item, move_item, get_next,
delete_item. Real items on your team's board, with type, status, priority, assignees and
history. Work the agent picks up shows as in progress and closes when it is done, so the board
is not a story someone has to retell.
Project memory - list_memory, get_memory, add_memory, update_memory, review_memory.
The durable knowledge of a project: the deploy that has a trap in it, the decision nobody should
relitigate, the command that is not in any README. Shared by everyone on the project, human or
agent. A new session reads it before acting instead of rediscovering it.
Reminders - add_reminder, list_reminders, update_reminder, delete_reminder. Things with
a date that must not be silently missed - and the agent closes or reschedules them itself once the
date arrives.
Attachments - add_attachment, get_attachment. Files that belong to an item.
Which project it writes to
Trail holds many projects. The connector uses the folder you have open as the project - the
folder name, or whatever a .trail file next to it says, or the TRAIL_PROJECT variable. So
the agent writes to the right project without being told, and two repositories never bleed into
each other. To reach across, the agent passes project explicitly on the tool.
Session hook (Claude Code, Gemini CLI, Antigravity)
Installed for you, once, when you log in - and on the connector's first run, which covers people who paste a token into the registration instead of logging in through the browser. Every session that starts in a project with a tracker gets the open items and the project memory in context from the first message - the agent starts knowing, instead of depending on someone remembering to ask. Fail-silent by design: no login or no network and the hook stays quiet.
Each tool keeps this in its own place, so the connector writes to the one that tool actually reads:
- Claude Code - a session-start hook in
~/.claude/settings.json. - Gemini CLI - a session-start hook in
~/.gemini/settings.json. - Antigravity - the tools are registered in
~/.gemini/config/mcp_config.json, which is the file it actually reads:gemini mcp adddoes not connect Trail in Antigravity, because that command writes to~/.gemini/settings.jsoninstead. Field-tested on Antigravity 2.11 (Windows), of the three things that live in that config folder only the tool registration is honored - the opening-summary hook is not run, and a plugin folder placed exactly where its own documentation says is not read. So on Antigravity the agent gets the tools and the server's working rules, and fetches the project summary itself on the first turn instead of receiving it. The plugin path is built and tested behind a switch, waiting for that to change.
usetrail status tells you, per tool found on this machine, whether it is on - so you never have
to go digging through settings files to find out.
It never fights you. A tool that isn't on the machine gets nothing created for it, and
hooks install will not fabricate a config for a program you don't have. If you remove it with
hooks uninstall, it does not come back on its own - put it back with:
Clients without a hook mechanism are covered too: the server's own instructions tell the agent to fetch the summary itself before acting.
Your own Trail
Point it at your server once and it stays pointed:
Without that variable, login goes to the hosted service.
Commands
The token is stored at ~/.config/trail/token.json (mode 600). Revoke it whenever you want from
the "AI token" panel in the app.
Configuration
The former names (TETHER_*) keep working, with no deadline - the product used to be called
Tether, and nothing anyone already configured has to change.
Updating
The @latest is not decoration. Registered as npx -y usetrail@latest, the connector resolves
the published version every time your agent starts a session, so a new release reaches you without
anyone doing anything. Registered as bare npx usetrail, npm reuses whatever copy it cached the
first time - and that machine stays on that version forever. Use @latest.
The cost of @latest is about a second at session start, and a network call. Neither matters in
practice: the connector talks to Trail over the network anyway.
A cloned install updates itself differently: on startup it fires a quiet fast-forward pull in the background, at most every six hours. The running session keeps the version it loaded; the next one starts updated. No network or a local conflict and nothing happens, silently.
Stuck on an old version? npx -y usetrail@latest doctor finds the install, reports the version and
unsticks it.
Requirements
Node 18 or newer.
License
MIT. This package is the client - the connector you run on your own machine. Use it, fork it, adapt it. The Trail service it talks to is a separate, hosted product.
Source: README.md at commit 0dcaad6
Tools
0Version history
2- v1.29.1LatestSep 18, 2026
- v1.29.0Sep 16, 2026
Score
50% of the applicable checks met
How complete this listing is, computed from the registry entry, the endpoint and public sources. Not a rating of the server and not a statement that it is safe or working today: reachability is a dated check, and no installs or reviews go into the score.
- Reached in the last 30 days25 pts
Keep the endpoint answering the MCP handshake; SourceWeft probes it every 30 days.
- Auth declared10 pts
Declare the credential headers in the registry entry, or keep the endpoint answering the probe so its auth can be classified.
- Tools listed15 pts
Answer tools/list without a credential, or ship a package that starts in a sandbox without one.
- DescriptionRequired15 pts
- Logo10 pts
- Documentation15 pts
- License10 pts