Skip to main content
Memex actions have one shared contract across the in-product agent, MCP, and API documentation. The contract records an action’s stable ID, compact purpose, required scope, effect level, approval requirement, and runtime bindings. The MCP server derives its complete tool manifest from this catalogue. The stable gateway consists of discover_actions and execute_action: discovery always returns execute_action plus the selected canonical action ID and current input summary. Named compatibility tools may still be generated for older clients, but discovery never routes new integrations through them. Backend runtime adapters provide only dependency-bound execution and response shaping. Do not add per-tool registrations to the MCP server bootstrap. Do not assume a listed capability is available to every connected agent. The server resolves the caller’s scopes before returning actions, and it remains the authorization authority when an action is invoked.

Discover only what is relevant

MCP clients should call discover_actions with the user’s intended outcome before selecting a tool. It returns at most six compact action cards, each containing the tool name, purpose, input summary, effect (read, write, or external), approval requirement, and required scopes.
The returned cards are intentionally brief. Call execute_action with the returned card’s id as actionId and an input object matching its current inputSummary. REST clients can make the equivalent authenticated request to POST https://memex.garden/api/actions/discover with { "request": "..." }. Its cards use the API binding and report the scope required for invocation.

Current actions

Execution policy

  • Read actions execute directly when the connection has api:read.
  • Write and external actions require api:write; their action contract also marks whether the Memex agent must create an in-product approval proposal.
  • Mutations normally require a readback completion check. Actions marked as self-verifying, such as tags.ensure_on_contents, enforce and return their own postcondition instead.
  • The catalogue helps an agent choose tools. It never grants permission and does not replace server-side authorization.
The in-product agent uses the same catalogue before each run to register only the small set of typed tools relevant to its workflow and request. This keeps normal chat turns from carrying unrelated tool schemas.