Repository navigation
⚠️ Action required: the default data folder has moved
Earlier versions kept cache, logs and .env next to the binary. As of 0.22.0 the default is the standard per-user location for your platform:
| Platform | New default |
|---|---|
| Windows | %AppData%\mcs-mcp |
| macOS | ~/Library/Application Support/mcs-mcp |
| Linux | ~/.config/mcs-mcp |
If you never set --data-path or DATA_PATH, the server starts with an empty cache and re-ingests your history from Jira on the next run. Nothing is deleted — your old folder is simply no longer read.
To keep your existing cache, either:
- point the server at the old folder:
--data-path /path/to/old/folder(or setDATA_PATH), or - move the contents of the old folder into the new location.
If you already set --data-path or DATA_PATH, nothing changes. Explicit configuration still outranks the default.
Why: the binary often lives somewhere the user does not own, or somewhere an update replaces wholesale — a cache kept beside it is then lost without a word. The new default also gives each platform the location its users expect.
Jira failures now tell the agent what to do
A failed call and an empty result used to look the same to the AI agent. A rejected credential read as "nothing found", so the agent retried with different search terms — burying the real cause and telling you your data was missing when Jira had never been successfully queried.
Failures are now classified (authentication, not found, unavailable, transport) and each carries an explicit instruction: stop, what to tell the user, and which setting to check. Rate-limits and outages in particular now say "try again in an hour" instead of provoking a retry storm.
You should notice this as: clearer, faster answers when something is misconfigured, instead of the agent flailing.
Cloud vs Data Center detection no longer depends on your token
Deployment flavour and authentication method were sharing a single setting. That worked only while every Cloud user authenticated with an API token — cookie-authenticated Data Center has no token to reason from, and was silently routed to Cloud v3 endpoints, producing 404s on projects that plainly exist.
The server now resolves the flavour by asking Jira directly (serverInfo), falling back to the host name only when that is unavailable. If your instance sits behind a custom domain and detection cannot settle it, the server says so and names the fix.
New setting: JIRA_DEPLOYMENT (cloud or datacenter) — leave unset unless the server tells you detection failed.
Configuration has one source of truth
Defaults previously lived in two places that had drifted apart: the shipped .env-example (which everyone copied) and the Go defaults (which is what you got without a config file). They disagreed on four variables. The .env template is now generated from the code defaults, so the file you edit and the behaviour you get cannot diverge.
Consequences worth knowing:
- Charts are on by default.
MCS_CHARTS_BUFFER_SIZEnow defaults to20in code. Previously the code default was0and charts only worked because the shipped.env-exampleset20. JIRA_TOKEN_TYPEis inferred from whetherJIRA_USER_EMAILis set. Set it explicitly only to override.- New flag:
--data-path, which outranksDATA_PATH. - On startup the server logs where every setting came from (
flag,env,dotenv,default,inferred). Secrets are logged as present/absent only.
Under the hood
- Upgraded to go-sdk v1.7.0, which targets MCP protocol revision
2026-07-28. The server speaks the new revision where the client supports it and the old one otherwise — no configuration change, no action needed. - Formatting is enforced across the tree; no behavioural change.
Changelog
- 5b2213c feat: classify Jira failures and tell the agent what to do about them
- 7bb02fe feat: default the data path to the per-user platform location
- e102835 fix: anchor context before pinning evaluation date in integration test
- dc7442f refactor: unify config bootstrap and make defaults authoritative
- 797aeeb style: gofmt the tree