Authentication & access

Connect with your server URL

In the Grok Bot app, add https://app.maury.ai/mcp. No client ID, client secret, API key, or pasted token is needed. Maury supports Client ID Metadata Documents (CIMD): compatible agents identify themselves with a public HTTPS document, which Maury validates before you approve access.

Maury accepts public clients using PKCE with token authentication method none. Metadata must be JSON served directly over public HTTPS on port 443, with an exact matching client_id, a client name, and declared callback URLs. Query strings, fragments, URL credentials, and redirects are not accepted for metadata URLs. Client identity and the callback hostname appear on the consent screen.

Pre-registered OAuth clients remain available for other integrations. Dynamic Client Registration and automatic confidential-client registration are not offered. The local CLI and API examples can still use a token from your own registered connection; your Maury password and normal website session are not MCP tokens.

The initial authentication challenge leaves scope selection to the client’s discovery flow. Grok Bot’s URL-only setup requests the advertised read, recording, editing, and proposal permissions together. To authorize only a subset, use a client or pre-registered connection that supports explicit scope selection. Approving a new grant never changes the permissions of existing tokens.

Choose what your agent can do

For scheduled ingestion with review, request only proposal permission. Add read access if the agent also needs to view saved-memory matches. Recording and editing permissions allow direct changes to saved information.

Recording, editing, and proposing are separate permissions. Use memories:read with memories:edit to correct memories; add memories:write to record new ones. Existing tokens keep their original permissions when refreshed. Reauthorize with the additional scopes and refresh your agent’s tools.

Complete the OAuth flow

For an application you’re building, use the authorization-code flow with PKCE S256. Keep the code verifier and validate the callback’s state value.

1. Send the user to the authorization endpoint with your CIMD document URL or pre-registered client_id, exact redirect_uri, response_type=code, requested scope, random state, code_challenge, code_challenge_method=S256, and the MCP resource.
2. The user signs in to Maury and reviews the requested permissions.
3. Exchange the returned code at the token endpoint using grant_type=authorization_code, your client ID, the code, code verifier, exact redirect URI, and the same resource. Public CIMD clients send no client secret. Pre-registered clients use their assigned authentication method.
4. Store the resulting tokens securely. Supply the access token to your agent through its supported credential mechanism.

The exact resource must be included in authorization, token-exchange, and refresh requests. MCP calls use Authorization: Bearer <access_token>. Tokens in query strings are not accepted.

Access tokens last one hour. Refresh with grant_type=refresh_token, your refresh token, client authentication, and the same resource. Refresh tokens rotate: securely replace the old refresh token with the newly issued one.

Tools for your memories

Proposal, recording, and replacement text accept up to 20,000 characters. The tools do not expose attachments, imported messages, contacts, or memory deletion.

Propose memories for review

Connect a compatible agent with memories:propose. An agent can send a useful fact from a chat to propose_memory with content, a UUID submission_id, and optional source conversation title and source_url HTTP or HTTPS link. Maury records the connected app’s name. The source title and link are supplied by the agent.

Memories saved directly through record_memory show the connected app as their creation source. When you save a proposal as a memory, Maury preserves the original app, proposal, and source-chat details. Reviewing a proposal in Maury Web does not replace its agent attribution. These creation details remain unchanged when you edit the memory or rename the connected app.

Before adding a proposal, Maury compares its meaning with your saved memories and earlier proposals, including saved and rejected history. A semantic comparison checks that an existing item covers all proposed facts without new or changed details. A confirmed match returns outcome: skipped_similar and the existing item instead of adding to your inbox. Otherwise, outcome: created contains a pending proposal. Similarity is approximate, so submit one durable fact per candidate and preserve meaningful details such as names, dates, and amounts.

A saved-memory match is checked even with proposal-only access. Reading its text, ID, link, or similarity score additionally requires memories:read; without that permission, memory is null and requires_read_permission is true. Proposal matches can be returned with proposal permission alone. A skipped result never means a new memory was saved.

Open Proposed Memories in Maury’s web app. Review each proposal, edit the text if needed, choose a brain, and select Save as Memory or Reject. Only saving creates a searchable memory; proposals remain private to your account, including when you share a brain. Saved and rejected proposals remain in review history. The MCP tools cannot approve or reject proposals.

Use your external agent’s scheduler, if it supports scheduled MCP calls and access to the source chats. Maury receives proposals; it does not schedule ingestion or give agents access to chats. Here is a prompt you can adapt:

On each run, review chats available to you since your last successful run.
Extract useful, durable facts I explicitly shared. Do not invent facts.
Check list_proposed_memories for pending, accepted, and rejected proposals;
follow next_before_id pagination. Avoid proposing the same fact again,
including facts I rejected, unless I explicitly ask to reconsider them.
Submit each candidate as one durable fact with propose_memory. Include the source chat title
and URL when available. Persist one UUID submission_id and the exact inputs
per candidate; reuse them on retries, including across scheduled runs.
Treat skipped_similar as handled; do not resubmit it with a new UUID.
Advance your checkpoint only after every submission succeeds.
Retry similarity errors with the same UUID.
Use proposals for this task. Do not call record_memory or update_memory.
Report proposals as awaiting my review in Maury, never as saved memories.

After a proposal is created, retries with the same UUID and identical inputs return that proposal and its current status. Changed inputs with that UUID are rejected. Skipped submissions store nothing and are checked again on retry, so deleting or editing a prior match can allow a later retry to create a proposal. If similarity checking fails, no proposal is created; retry with the same UUID. Saved memories are checked through the available search index and become candidates after normal indexing finishes. list_proposed_memories defaults to status: pending; use accepted or rejected to check history. Pass next_before_id as before_id for the next page. Stop when it is null.

Correct the original memory

Ask your agent to update the memory when a detail is wrong. It should fetch the memory first, review the full text, then call update_memory with the memory’s id, the complete corrected text as content, and the fetched revision as expected_revision.

This replaces the text in place and preserves the ID, brain, original audio, and attached files. Preserve all unrelated details. Fetch returns the correction immediately; search catches up after indexing.

Stay in control

Review or revoke a connection in Connected apps, also linked from Maury Settings. Revoking a connection invalidates its grants and tokens for your account. Access to each brain is checked on every tool call.

A few common questions