User MCP Catalog
How user OAuth MCP discovers, prepares, executes and recovers operations from the shared NeatLogs catalog.
User MCP exposes a small set of generic protocol tools. Product actions are discovered from the backend operation catalog rather than installed as hundreds of individually named tools. Availability depends on the deployment, signed-in actor, scopes, organization/project context and feature gates.
See connection setup before using this interface. The legacy project-key tools belong to a different endpoint and catalog.
Discovery and execution
| Tool | Purpose |
|---|---|
get_execution_identity | Identify the current authenticated execution principal. |
search_actions | Find relevant permitted product actions in the live catalog. |
describe_action | Read the operation's schemas, target/context, credential policy, effect, confirmation, limits and recovery rules. |
prepare_action | Validate and reserve an invocation without dispatching the feature action. |
run_read_action | Execute a prepared read using the original registered policy/handler pipeline. |
run_write_action | Execute a prepared write or compute action under its declared confirmation and admission rules. |
get_action_status | Read current invocation state under current authorization. |
cancel_action | Request cancellation; accepted work may still require settlement. |
get_action_result | Read an eligible confirmed mutation result using the original invocation. |
get_saved_action_result | Recover an eligible original mutation response using its operation, input and idempotency key after invocation expiry; does not repeat the mutation. |
get_compute_execution / cancel_compute_execution | Inspect or cancel a durable compute execution under its current lifecycle policy. |
read_action_result | Read a declared retained result in digest-checked chunks under current authorization. |
Agents must negotiate the catalog version and schema dialect advertised by the server. Catalog v2 is a read-only HTTP/JSON compatibility path. Catalog v4 supports the canonical execution protocol; do not substitute a schema dialect from another version or silently fall back after rejection.
What an action descriptor contains
The descriptor identifies the operation's HTTP method/path and operation ID, input and response schemas, semantic headers, target/context, allowed credential kinds, OAuth scopes/permissions, read/write/compute effect, confirmation, idempotency and result/recovery behavior. These fields describe the contract; the backend still checks current access at execution and recovery.
CLI and MCP reuse the registered Public API handlers and existing feature services. A matching catalog entry does not prove successful execution, feature activation, usable fixtures or external-provider readiness. A successful job admission does not prove worker completion or artifact contents.
Credential differences
User OAuth cannot execute an operation that requires a service-account or guest credential. The DEV integration inventory intentionally excludes user credentials from external incident ingestion, service-account incident-review publication and the two guest-review token operations. Keep those dedicated credential paths separate; do not add user MCP access to make catalog counts match.
Secret-producing operations require the supported native custody transport. Wrapped results stay outside the model; explicit local reveal is a separate human action. Do not put unwrapped keys or guest secrets in tool input, a conversation, logs or configuration.
Context, errors and limits
Use accessible organization/project IDs from normal discovery. The OAuth application client ID is not a user ID. Current membership, resource state, scope and applicable quotas can deny a previously discoverable action.
Use only descriptor-declared parameters, query keys, bodies and semantic headers. Respect explicit pagination limits. Preserve canonical error code/status and distinguish a rejection before invocation from an unknown outcome after sending a write. Never retry an uncertain mutation or job under a fresh key.
Large results must be consumed completely through the declared result protocol with digest/version checks. Receipt capacity and other limits remain enforced across tokens/clients for the same principal; changing identity/project to bypass them is not recovery.
Activity and validation
Canonical access auditing and feature lifecycle audits are separate from short-lived invocation state. Audit visibility is governed by the product's normal roles and entitlements, and it is not a conversation transcript.
Integration acceptance compares existing working native API/CLI operations with MCP inputs, responses/errors, persisted effects and applicable artifacts/recovery. The DEV operation inventory and live scenario evidence are versioned separately. Classifier training/prediction remains deferred in the current acceptance scope; it is not presented as tested merely because its operations can be discovered.