https://movingmanifest.com/mcpCanonical
Stateless Streamable HTTP with OAuth sign-in, then a person-approved product grant. Serves the catalog listed on this page and nothing outside it.
The canonical endpoint takes an OAuth sign-in and then obeys a product grant the person approves. Three other doors exist for compatibility, keys, and local use; their catalogs are not the same.
MCP path
Your AI calls tools
User signs in to Assist With Moving.
Their AI connects to the canonical door, or a key-only door for headless tools.
The user approves a grant; only the tools it covers are listed.
Revoking the grant refuses the very next call.
OAuth proves who is calling. A separate product grant, approved by the person and re-read on every discovery and every call, decides which moves, which data, and which operations. Revoking it refuses the very next call.
tools/list shows only the tools the current grant covers, so nothing is advertised that would only be refused. describe_connection is always listed and needs no scope.
Connect to https://movingmanifest.com/mcp and sign in — no key to copy. The API-key door at https://movingmanifest.com/api/mcp is a separate surface with a separate catalog for headless or non-OAuth tools.
Canonical clients call describe_connection when nothing is listed, then get_move_brief. API-key clients use get_api_capabilities, because that automation catalog is different and larger.
A Client ID Metadata Document is preferred, validated, and its digest bound to the grant. Dynamic registration is a labelled fallback. A metadata document that fails validation is refused, never downgraded.
save_complete_result keeps a finished plan, its inventory, locations, decisions, estimates, and source checks together in one replay-safe operation — and can close the Queue handoff in the same approval.
An OAuth-capable AI can connect without the person handling a raw secret. Settings manages the grant, revocation, and the API-key fallback for local or headless tools.
The requirement is remote Streamable HTTP MCP plus compatible OAuth; no local process and no repository clone. That is a capability requirement rather than a list of AI products, because no product has yet completed a full lifecycle here.
Canonical MCP endpoint
https://movingmanifest.com/mcp
OAuth-capable clients
Paste this MCP URL into any AI that speaks remote Streamable HTTP MCP with compatible OAuth: https://movingmanifest.com/mcp Then sign in with your Assist With Moving account — no key needed. The client discovers the authorization server from: /.well-known/oauth-protected-resource/mcp Signing in is not permission. Approve a grant in Settings afterwards, or the connection will list only describe_connection.
Advanced: API-key door (headless / non-OAuth only)
Advanced — headless / non-OAuth clients ONLY. This door is key-only, never advertises OAuth, and rejects OAuth sign-in. It serves a different catalog from the canonical door. POST https://movingmanifest.com/api/mcp Authorization: Bearer mmk_replace_with_a_scoped_api_key
In a client that supports custom connectors, add Assist With Moving by pasting the endpoint URL. If the client cannot do OAuth, create a scoped helper key and supply it as the bearer token (or an x-api-key header) to the API-key door instead. Do not paste raw keys into OAuth-capable clients. Passing the key in the URL (?key=...) is no longer supported — URLs get logged, so a key that has ever been in one should be rotated.
The Queue loop is list_queue_work, claim_queue_work, then either ask_queue_question for the smallest Needs you question or release_queue_work to hand it back, and finally complete_queue_work. A Queue directive says what the person wants; it never widens the grant.
Rules for the canonical door
1. describe_connection when no tools are listed — it says what to ask for. 2. get_move_brief first; use only the move and record IDs it returns. 3. search_move_records before creating anything. 4. get_evidence_media for private photos — never a private page or storage URL. Delivery is budgeted; anything left out is listed under skipped with a reason. 5. save_complete_result to finish, with completeQueueItem to close the handoff. 6. Reuse operationId on a retry so it corrects instead of duplicating. 7. Stale tools after a deployment: disconnect, then reconnect.
Every write takes an operationId, and corrections carry expectedUpdatedAt or expectedVersion, so a retry corrects the earlier attempt instead of duplicating it. Archive is reversible and is the only destructive verb this connection ever gets: it cannot permanently delete, archive a whole move, publish, share, export, manage household access, or act outside Assist With Moving.
These are all the tools the canonical door can ever serve, and a connection is shown only the ones its grant covers. Sale, export, household admin, photo upload, and raw CRUD are not in it.
no scope — always available
describe_connection
moving.context.read
get_move_brief, search_move_records, get_move_records
moving.evidence.read
get_evidence_media
moving.work.write
save_move_context, save_inventory, save_planning_record, save_complete_result
moving.queue.work
list_queue_work, claim_queue_work, release_queue_work, ask_queue_question, complete_queue_work
moving.archive
archive_move_records
A separate catalog on a separate door, available when a user intentionally creates a broader API-key connection.
Move creation and setup for headless automations
Detailed item and box primitives for advanced partial workflows
Sale-prep workflows when the user grants that scope intentionally
Export and share workflows when the user grants documentation access
Household collaborator management for admin-approved local helpers
Layout Studio operations for plan review and editing
Raw upload sessions for clients that cannot use workflow photo tools
A tool that works on one door proves nothing about another. Check the live catalog of the door you actually connected to.
Stateless Streamable HTTP with OAuth sign-in, then a person-approved product grant. Serves the catalog listed on this page and nothing outside it.
The older persisted OAuth gateway, kept working for clients that already connected there. A different and larger catalog, governed by that gateway rather than by product grants. Not an alias of /mcp.
Accepts a scoped mmk_ key, never advertises OAuth, and rejects OAuth tokens. Its own separate catalog and scopes.
Runs locally against the REST API with a scoped mmk_ key. Serves the API-key catalog, not the canonical one.
The endpoint, product scopes, grant boundary, Queue workflow, and immediate revocation are implemented. No AI product has completed a full connect, grant, read, evidence, save, revoke, and reconnect lifecycle against it, so the whole connection is Partial rather than Current.
The resource prefers, validates, and refuses Client ID Metadata Documents in code, but the provider-side configuration that enables that path is not yet done, so dynamic registration is still what clients meet in practice. The grant screen itself is Current: approve, review, and revoke in Settings.
With no connection at all, a person can copy a Queue item's bounded brief into any AI and paste the result back into the same item. The handoff completes without MCP, OAuth, or a key.