Actioner MCP Server

Overview

Actioner watches a customer-facing team’s email, calendar and CRM, builds an account memory from them, and turns what it finds into action items. The MCP server exposes that workspace to Claude: schema discovery and SQL-backed reads over the user’s own data, interactive forms for anything that leaves the workspace (email, calendar invites), immediate writes for record edits, and one generated tool per saved process (“play”) the organization has authored.

Server name

actioner-mcp-server

Display title

Actioner

Version

1.0.0

Endpoint

https://api.actioner.com/mcp

Transport

Streamable HTTP

Session model

Stateless (no Mcp-Session-Id)

Authentication

OAuth 2.1 + DCR

Tools

58 static + 1 per saved play

Resources

3 reference + 8 UI

Rate limit

120 req / 60 s / user

Primary use cases

• Account review. “What changed on Aurora Freight since our last call?” — Claude reads the account’s interactions, deals, health and open action items.
• Working the action box. Claude surfaces the user’s pending action items in an interactive view, then marks them done, snoozes, or dismisses them on the user’s instruction.
• Meeting prep and follow-up. Claude drafts an agenda from the account’s recent history, and drafts the follow-up email for the user to review and send.
• Pipeline and portfolio questions. Aggregate SQL over the user’s own workspace — renewal exposure by segment, deals with no activity in 30 days, health-score distribution.
• Running saved processes. Each play the organization has authored appears as its own tool, so Claude can execute the team’s documented methodology instead of improvising one.

The connector both reads and writes. Every write is either explicitly requested by the user in chat or confirmed by the user in an interactive form before it is applied.

Setup

Prerequisites

• An Actioner account. Sign-up is self-serve; a workspace is created on first sign-in.
• At least one connected source of customer data. Actioner connects to Gmail or Outlook, Google or Microsoft calendars, and CRM sources such as HubSpot. A workspace with no connected source will answer schema questions but return empty result sets.
• No plan upgrade or admin approval is required to connect the MCP server; any signed-in member can connect it to their own Claude account.

Connecting from Claude

1. In Claude, open Settings → Connectors and add Actioner (or, before directory listing, Add custom connector with the URL https://api.actioner.com/mcp).
2. Claude registers itself with Actioner’s authorization server automatically and opens the Actioner sign-in page.
3. Sign in and pick the workspace to connect. Actioner shows a consent screen listing what Claude will be able to reach.
4. Claude returns to the connector list showing the Actioner tools. The connection is bound to that one user in that one workspace.

What the user sees on first use

Nothing needs configuring after connecting. Tool discovery is read-through per request: the tools a user sees include one play_<name> tool for every enabled play in their workspace at that moment, so a play saved during a conversation becomes callable in the next one.

Disconnecting

Removing the connector in Claude revokes the tokens client-side. Actioner also accepts POST /mcp/logout, which clears the server-side connection state for the authenticated user. Workspace owners can review and revoke connected clients in Actioner’s workspace settings.

Using the connector

Representative prompts, and what Claude does with them:

Discovery order for data questions

The server instructs Claude to call get_schema() before writing SQL, then get_schema({ tables: [...] }) for the specific views a query touches. Column names are never guessed. query_data is for aggregates; list is for rows a user would browse and click into.

Authentication

Actioner is an OAuth 2.1 authorization server and protected resource. Claude connects with the standard remote-MCP flow: metadata discovery, dynamic client registration, authorization code with PKCE. No API keys, no shared credentials, no user-supplied URL.

Unauthenticated requests to /mcp return 401 with a WWW-Authenticate header pointing at the protected-resource metadata.

Permission model

Every tool carries annotations — a human-readable title plus the applicable readOnlyHint / destructiveHint / openWorldHint — so Claude can apply auto-permissions correctly. The three access classes used throughout this document map directly to those annotations:

Reads and writes are separate tools

There is no catch-all request tool and no tool that takes a method or an operation-type argument to decide whether it reads or writes. Writes are split by action: create and update are distinct tools; deletion is its own tool per entity family (delete_artifact, delete_template). The freeform-SQL tools (query_data, list, test_query) run through a physically read-only execution path — see Security.

Draft-then-confirm for anything that leaves the workspace

Email and calendar actions are two-step by design. Claude calls the read-only draft tool (compose_email, create_meeting, update_meeting), which opens a prefilled form in the conversation. Nothing is sent or scheduled until the user submits that form, which invokes the corresponding _submit_* tool. The draft tools are annotated read-only because they genuinely are: they render a form and mutate nothing.

The single exception is send_notification, which sends the user an email from their own account to themselves — used for “email me this summary”. It sends immediately and is annotated as a write reaching an outside system.

Tool reference

58 tools are registered on every connection, plus one generated tool per enabled play (see Play tools). Tools whose names begin with an underscore are invoked by Actioner’s own interactive views, not chosen by Claude from the tool list; they are documented here for completeness and are marked UI-invoked.

Schema, data access, and action items

Records, email, calendar, artifacts, and preferences

Form lookups

UI-invoked lookups that populate comboboxes inside Actioner’s interactive views. All read-only, all scoped to the caller’s workspace.

Plays, templates, and process locks

Tools for creating and maintaining the workspace’s own saved processes. Template authoring tools are restricted to workspace administrators; a non-admin call is refused with an explanatory error. See Play tools for how a saved play is then executed.

Play tools

A play is a process the customer’s own team has written down — how they run an at-risk review, prepare a QBR, or work a renewal. Each enabled play is registered as its own MCP tool named play_<name>, with the play’s parameters as its input schema, its own description, and annotations titled Run play: <name>.

Because plays are authored by users, the tool list is generated per request from the workspace’s enabled plays. That has three consequences a reviewer should expect:

• Two different accounts will show different play_* tools. A brand-new account may show none.
• The total tool count varies. The 58 static tools are always present.
• Annotations are generated with the tool, so every play tool always carries a title and hints — a newly saved play needs no separate registration step.

Executing a play is read-mostly: it runs the play’s compiled read-only queries and returns the methodology plus the account context the methodology needs. Any change to the workspace happens through the ordinary write tools above, each with its own annotation and confirmation behavior. Play tools are annotated as writes rather than read-only for that reason.

find_or_run_play_fallback Write is the catch-all entry point for the same saved processes, used when a play was saved after the client last listed tools. It resolves the process by name and runs it, or lists the processes missing from the caller’s tool list.

Interactive UI

Actioner is an MCP App: several tools return an interactive view rather than plain text, declared through _meta.ui.resourceUri and served as ui:// resources. The views are how the connector keeps confirmation in the user’s hands — a draft email is shown as an editable composer, not described in prose and sent.

The views call back only into the underscore-prefixed tools listed in the reference above, each of which is annotated and permission-checked exactly like any other tool.

Resources

Three reference resources let Claude learn the data model without spending tool calls on it:

Data handling

What the connector reaches

Only the authenticated user’s own Actioner workspace: accounts, contacts, deals, entitlements, health records, notes, meetings and conversations, action items, saved artifacts, and the plays and templates the workspace has authored. Actioner’s own APIs are first-party; the connector calls no third-party API on the user’s behalf beyond the mailbox and calendar the user has themselves connected to Actioner.

What it does not reach

• Claude’s memory, chat history, conversation summaries or user files. No tool reads any of them.
• Other users’ or other workspaces’ data. Workspace scoping is derived from the access token, not from tool arguments, so a caller cannot widen their own scope by passing a different id.
• Conversation content beyond the arguments a tool needs to do its job. Tool-call telemetry (tool name, outcome, duration) is recorded for reliability monitoring.

Where the data lives

Depending on the workspace’s deployment, a tool call is served either from Actioner’s cloud or forwarded over the user’s authenticated device connection to Actioner’s local companion app, where that user’s workspace data is stored on their own machine. The tool surface, annotations and permission behavior are identical either way; in the local case the customer’s underlying records never leave their device to answer the call.

Retention and deletion

Records created through the connector follow the workspace’s ordinary retention: they live until deleted by a user or until the workspace is deleted. Deleting the workspace deletes its data. Disconnecting the connector stops all access immediately and leaves previously created records in place.

Full detail — collection, use, storage, sub-processors, sharing, retention and contact — is in the privacy policy at https://actioner.com/privacy-policy.

Security

Errors and limits

The endpoint accepts POST /mcp only. GET /mcp is refused — the server does not offer an SSE stream — and DELETE /mcp is accepted as a no-op, since there is no session to terminate.

Reviewer test guide

Test credentials for a fully populated workspace — accounts, deals, meetings, email history, action items and several saved plays — are supplied with the submission. Sign in to the Actioner app with those credentials once before connecting, so the workspace is selected.

Suggested pass

1. Connect. Add the server as a custom connector at https://api.actioner.com/mcp. Confirm the sign-in and consent screens appear and the tool list loads.
2. Discovery. Ask “what data can you see about my accounts?” — exercises get_schema and the reference resources.
3. Aggregate read. “How many open deals do we have by stage?” — exercises query_data.
4. Browsable read. “List the deals closing this quarter.” — exercises list and its interactive table.
5. Entity view. Open any account by name — exercises show and companies.
6. Action items. “Show my action box”, then mark one done and snooze another — exercises show_actionbox, markdone_action_item, snooze_action_item.
7. Draft-then-confirm. “Draft a follow-up email to the contact on that account” — confirm the composer opens and that nothing is sent until you submit it.
8. Calendar. “Set up a 30-minute check-in next Tuesday” — confirm the event form opens prefilled and creates only on submit.
9. Write. “Add a note to that account” — exercises create.
10. Play. Call one of the workspace’s play_* tools — exercises the generated-tool path end to end.

Every tool in this document has been exercised by the Actioner team through the MCP Inspector and as a custom connector in Claude. An automated end-to-end suite drives the full tool surface against a seeded workspace on every release.

Review criteria

How this connector meets each published requirement:

Support

Breaking changes to a tool’s name or input schema are released as a new server version, announced in the product changelog before the change ships. Security reports are triaged on receipt at the support address above.