25 posts tagged with "mcp"

• Fixed. motorical_get_onboarding_state was listed on the analytics server under read:analytics, but the API route behind it needs a different scope (config.read) that read:analytics does not carry. A connection holding only read:analytics saw the tool and got 403 missing_scope.
• Now. The tool needs read:domains (which carries config.read) and is listed on the domains server and main. A connection without a domains read no longer sees it, instead of seeing it and being refused. Nothing that worked before is lost: the tool never worked for the connections affected.
• Why not every connection. Unlike motorical_whoami, it reports domain verification, DNS readiness and Motor Block state, which an agent that only sends or only reads analytics has no reason to enumerate.
• A check keeps scopes honest. The documentation build now compares every MCP tool's scope with the scope its API route requires; these two tools were the only mismatches.
• Packages. @motorical/mcp 1.22.0 and @motorical/scope-catalog 0.7.0 are on npm; the hosted servers already run the change.

Documentation changed

• MCP tool reference
• Hosted MCP Resource Server
• Operate and report on a live account (MCP)
• Motorical for Agents

• Fixed. motorical_whoami was listed under read:analytics, but the API route behind it needed a different scope (config.read) that read:analytics does not carry. A connection holding only read:analytics saw the tool and got 403 missing_scope; a connection holding only send:transactional or manage:webhooks never saw it.
• Now. Any OAuth connection can call it, whatever scopes it holds, and every hosted server except signup lists it, so an agent can always ask what it holds. It stays visible after the sandbox phase.
• Unchanged. Every other credential (an account-key token, a dashboard token) still needs config.read to read it, because the owner email is returned in full.
• Packages. @motorical/mcp 1.21.0 and @motorical/scope-catalog 0.6.0 are on npm; the hosted servers already run the change.

Documentation changed

• Operate and report on a live account (MCP)
• MCP tool reference
• Hosted MCP Resource Server
• Local MCP Server
• Endpoints

Everything you can only look at on a domain no longer needs permission to change domains.

• Health and config with read access. motorical_get_config and motorical_get_domain_health now need only the read:domains permission. Before, they needed manage:domains, which also lets an agent add and verify domains.
• Three new read-only tools on the main and Domains servers: motorical_domain_get (one domain), motorical_domain_dns_records (the records to publish, with optional live lookup) and motorical_domain_health (SPF, DKIM and DMARC health of one domain by id, for domains that do not have a Motor Block yet).
• Matching Public API routes: GET /api/public/v1/domains/{id}, /domains/{id}/health and /domains/{id}/dns-records, all with the config.read scope.
• Removing a domain is not offered to agents. It stays in the dashboard.

If you use the local server, update to @motorical/mcp 1.14.0.

Documentation changed

• Hosted MCP Resource Server
• Local MCP Server

An agent connected to a hosted Motorical MCP server no longer sees the sandbox tools (motorical_sandbox_status, motorical_sandbox_provision, motorical_sandbox_convert and the motorical_free_recipient_* tools) once your account has a verified domain of its own, an active plan, and has moved out of the sandbox (converted it, or gone straight to production). They only exist to get a new account to its first real send, so after that they were noise that invited wrong calls.

• The rule needs all three. A Free account on its own domain is still in the sandbox and keeps these tools until it has a plan, and an account with a domain and a plan keeps them until the sandbox is converted, because converting is its next step.
• It changes what an agent is told about, not what your account may do. Reconnecting is not needed; the next time the client lists tools it sees the shorter list.
• The local @motorical/mcp server is unchanged.

Documentation changed

• Hosted MCP Resource Server
• Motorical MCP

• New tool: motorical_whoami. An agent can now ask who it is acting for instead of guessing. It returns the account (id, owner email, name), the plan, and, over OAuth, the permissions the connection holds, the Motor Blocks it covers and the permissions that could still be added, with the page where you add them. The Public API route is GET /api/public/v1/account/whoami.
• Motor Block usage shows real numbers. The daily, hourly and burst usage of a single Motor Block (dashboard, GET /motor-blocks/{id}/rate-limits and the overview) used to read 0 whatever you had sent. It now matches what was actually sent. Account-level usage was already correct.
• Cleaner tool list over OAuth. The two 6-digit-code allowlist tools, which only ever worked from a dashboard session, are no longer listed to an OAuth connection; use motorical_free_recipient_add there. Domain tool descriptions now state the scope they need. motorical_get_logs documents its query terms (code: and id:).

If you use the local server, update to @motorical/mcp 1.13.0.

Documentation changed

• Hosted MCP Resource Server
• Local MCP Server
• Endpoints