Amendary for coding agents (MCP)

A single remote MCP endpoint on your Amendary backend. It speaks the standard JSON-RPC tool flow: a client initializes, lists tools and calls them. Four tools are exposed, and they map one-to-one to the four read endpoints of the REST API, so an agent and a CI script read exactly the same data.

The endpoint URL, protocol version, a sample client configuration and the full tool and field reference live in the help pages: API and MCP and the REST API reference.

• List pending and recent corrections, each with its evidence: the source, the changed paths, the stale quote and the planned edit.
• Read per-repo freshness: when a repo was last checked, which sha it was compared against, the last run's outcome and how many corrections are still pending.
• Read the workspace's token-usage summary, the same numbers Settings shows.
• List the mapped pages for a repo with a freshness record and each page's own Notion or GitHub URL.

Page listings return metadata and links, not page contents. Correction records can include the stale quote, the proposed text and the replaced blocks a reviewer needs.

• Approve, apply or dismiss a correction.
• Edit, comment on or create a page in Notion or GitHub.
• Change a setting, a mapping or the review mode.
• Spend model budget or trigger a check.

There is no write surface. The MCP server and the REST API dispatch to the same read handlers, and contract tests keep their result shapes aligned. Applying or dismissing a correction happens in the dashboard, by a person, under the workspace’s review mode.

A workspace owner creates a key under Settings, API keys. The key is shown once and starts with amk_. Amendary stores only its hash, a short prefix, creation and last-used times, and revocation state, so a lost key cannot be recovered; create a new one and revoke the old.

Each key is bound to one workspace and selects it, so there is no workspace header to set. The same key works for the REST API and the MCP server, sent as a bearer token. Keys are rate limited per minute and can be revoked immediately. Reads are not written to the Activity log, so a busy agent cannot flood it.

• An agent working in a repo asks whether that repo’s docs are behind before it opens a PR.
• An agent reads the pending corrections for a page and summarises them for the person reviewing.
• A CI step reads pending corrections over REST and warns on a pull request.
• A scheduled job reads the usage summary and posts it to a channel.

Keep the key in the client’s secret or environment-variable facility rather than committing it to a repository. This is the currently supported remote MCP subset; broader client compatibility, discovery and OAuth are roadmap work, not implied support for every client.

Amendary’s review policy is what makes an automatic edit safe to trust: hard ungrounded values, removals and most additions wait for a person. A write surface for agents would let a tool bypass that policy. The REST and MCP surfaces exist so your tools can see the state of your docs, while the decisions stay with the people who own the pages. More on isolation and access control in Security.