Connect EveryAction to Claude: Track Fundraising and Field Organizing

If you need to connect EveryAction to Claude to automate donor outreach, track campaign contributions, or manage field organizing data, you need a Model Context Protocol (MCP) server. This server acts as the translation layer between Claude's natural language tool calls and EveryAction's REST API. You can either build and maintain this infrastructure yourself, or use a managed integration platform like Truto to dynamically generate a secure, authenticated MCP server URL. If your team uses ChatGPT, check out our guide on connecting EveryAction to ChatGPT or explore our broader architectural overview on connecting EveryAction to AI Agents.

Giving a Large Language Model (LLM) read and write access to a sprawling political and nonprofit CRM like EveryAction is a significant engineering challenge. You have to handle specific authentication schemas, map complex nested JSON payloads to MCP tool definitions, and deal with strict rate limits. Every time EveryAction updates an endpoint or deprecates a field, you have to update your custom server code, redeploy, and test the integration.

This guide breaks down exactly how to use Truto to generate a secure, managed MCP server for EveryAction, connect it natively to Claude Desktop, and execute complex fundraising and canvassing workflows using natural language.

The Engineering Reality of the EveryAction API

A custom MCP server is a self-hosted integration layer. While the open MCP standard provides a predictable way for models to discover tools, the reality of implementing it against EveryAction's API is painful. You are not just integrating a simple CRM - you are integrating a highly specialized system built for political campaigns and massive nonprofits.

If you decide to build a custom MCP server for EveryAction, you own the entire API lifecycle. Here are the specific challenges you will face:

The VAN ID Identity Crisis EveryAction (originally built on the NGP VAN architecture) relies heavily on internal VAN IDs for identity resolution. However, the system also accepts heavily encoded identifiers (like EID28CG). If you expose these raw lookup parameters to Claude without strict schema constraints, the model will frequently hallucinate ID formats or attempt to pass standard integers where encoded strings are required. A managed MCP server forces the LLM to adhere to strict validation rules before the request ever hits the API.

Complex Bulk Import Payloads Field organizing often requires bulk data manipulation. EveryAction's bulk import endpoints do not simply accept an array of JSON objects. Instead, you must provide a payload containing a sourceUrl pointing to a zipped, delimited file hosted on an SFTP, FTPS, or HTTPS server, alongside a complex actions array that maps specific file columns to Contacts, Contributions, or Activist Codes. Teaching Claude to construct this payload from scratch is highly error-prone. Truto abstracts this by providing a clean, strongly typed MCP tool schema derived directly from accurate API documentation.

Aggressive Rate Limiting and Error Handling EveryAction enforces strict rate limits to protect their infrastructure, especially during election cycles or major fundraising pushes. When these limits are hit, the API returns a 429 Too Many Requests status. It is critical to note that Truto does not automatically retry, throttle, or apply backoff on rate limit errors. When the upstream EveryAction API returns an HTTP 429, Truto passes that error directly to the caller.

However, Truto does normalize upstream rate limit information into standardized headers (ratelimit-limit, ratelimit-remaining, ratelimit-reset) following the IETF specification. This means the MCP client (Claude) receives standardized context about the rate limit, but your agent architecture is ultimately responsible for interpreting the 429 error and executing the retry and exponential backoff logic.

Instead of building a server to handle these API quirks from scratch, Truto dynamically generates tools based on curated API documentation, enforcing schemas and normalizing auth so you can focus on agent behavior.

How to Generate an EveryAction MCP Server with Truto

Truto creates MCP servers dynamically. Tools are generated from the integration's resource definitions and documentation records. A tool only appears in the MCP server if it has a corresponding documentation entry - this acts as a quality gate to ensure only well-documented endpoints are exposed to the LLM.

There are two ways to generate an MCP server in Truto: via the UI or via the API.

Method 1: Generating the Server via the Truto UI

For quick prototyping and manual setup, the Truto dashboard provides a simple interface.

1. Navigate to the Integrated Accounts page in your Truto dashboard and select your connected EveryAction account.
2. Click the MCP Servers tab.
3. Click Create MCP Server.
4. Select your desired configuration. You can name the server, filter by specific methods (e.g., only allow read operations), or filter by tags (e.g., only expose fundraising endpoints).
5. Click Save, and immediately copy the generated MCP server URL (e.g., https://api.truto.one/mcp/abc123xyz...).

Method 2: Generating the Server via the API

For programmatic, multi-tenant deployments, you can dynamically spin up an MCP server scoped to a specific integrated account using Truto's REST API. The API validates that the integration has tools available, generates a cryptographically secure token, stores it in a distributed edge data store, and returns a ready-to-use URL.

Endpoint: POST /integrated-account/:id/mcp

// Example: Creating an EveryAction MCP Server restricted to read-only tools
const response = await fetch('https://api.truto.one/integrated-account/YOUR_ACCOUNT_ID/mcp', {
  method: 'POST',
  headers: {
    'Authorization': 'Bearer YOUR_TRUTO_API_KEY',
    'Content-Type': 'application/json'
  },
  body: JSON.stringify({
    name: "EveryAction Read-Only Agent",
    config: {
      methods: ["read"],
      tags: ["fundraising", "organizing"]
    },
    expires_at: "2026-12-31T23:59:59Z"
  })
});
 
const mcpServer = await response.json();
console.log(mcpServer.url); 
// Outputs: https://api.truto.one/mcp/<secure_token>

The URL returned contains a cryptographic token that encodes the account routing, tool filters, and expiration. No additional configuration is needed on the client side - the URL alone authenticates the MCP connection.

How to Connect the MCP Server to Claude

Once you have your Truto MCP server URL, you need to connect it to Claude. All communication happens over HTTP POST using JSON-RPC 2.0 messages.

Method A: Connecting via the Claude Desktop UI

Anthropic allows you to easily connect remote MCP servers directly through the Claude application settings.

1. Copy the MCP server URL generated by Truto.
2. Open Claude Desktop.
3. Navigate to Settings -> Integrations -> Add MCP Server.
4. Paste the Truto MCP URL into the connection field and click Add.

Claude will immediately perform an initialization handshake (initialize) with the server, requesting the available tools (tools/list). Your EveryAction tools are now ready to use in chat.

Method B: Connecting via Manual Configuration File

If you are configuring Claude Desktop manually or running it in a headless environment, you can update the claude_desktop_config.json file to point to your new server. Because Truto MCP servers use standard HTTP POST (Server-Sent Events / JSON-RPC), you use the official remote MCP client transport.

Locate your configuration file (usually at ~/Library/Application Support/Claude/claude_desktop_config.json on macOS or %APPDATA%\Claude\claude_desktop_config.json on Windows) and add the following:

{
  "mcpServers": {
    "everyaction-truto": {
      "command": "npx",
      "args": [
        "-y",
        "@modelcontextprotocol/server-sse",
        "--url",
        "https://api.truto.one/mcp/YOUR_SECURE_TOKEN_HERE"
      ]
    }
  }
}

Restart Claude Desktop. The application will connect to the server and pull down the EveryAction tool definitions automatically.

Security and Access Control

Giving an LLM access to sensitive political or donor data requires strict governance. Truto provides several layers of security to ensure your MCP servers cannot be abused:

• Method Filtering: Restrict an MCP server to only read operations (get, list), only write operations (create, update, delete), or custom actions. This prevents a research agent from accidentally deleting contact records.
• Tag Filtering: Group tools logically. You can create an MCP server that only has access to tools tagged with fundraising, completely isolating the agent from field_organizing data.
• Require API Token Auth (require_api_token_auth): By default, the MCP URL is a bearer token. For higher security, you can toggle this flag to force the MCP client to also pass a valid Truto API token in the Authorization header, adding a strict secondary layer of authentication.
• Automatic Expiration (expires_at): Assign a time-to-live (TTL) to the MCP server. Truto uses background edge scheduling to automatically destroy the server and revoke the URL at the specified ISO datetime, perfect for granting temporary access to contractors or short-lived AI workflows.

EveryAction Hero Tools for Claude

Truto automatically generates descriptive, snake_case tool names based on the EveryAction resources. When Claude calls a tool, the input arguments are mapped directly against the strict JSON Schema derived from the API docs.

Here are the highest-leverage tools available for your AI agents.

every_action_people_search

This is the starting point for almost all EveryAction workflows. It allows the agent to look up an individual using a variety of match candidates (email, phone, name, DOB) or directly via a VAN ID.

Contextual usage notes: The tool returns extensive biographical data including employer, occupation, and custom properties. If an agent has a VAN ID, it will override all other search criteria for a direct lookup.

"Claude, search EveryAction for a donor named Jane Doe with the email jane.doe@example.com. Extract her VAN ID and current employer data."

list_all_every_action_contributions

Retrieves the recent financial contributions associated with a specific individual.

Contextual usage notes: This requires a valid vanId (usually retrieved via the search tool). It returns detailed transactional data including the source code, designation, amount, and date received. Perfect for preparing donor briefing sheets.

"Using the VAN ID we just found, list all of Jane Doe's past contributions. Summarize her total giving and list the top three source codes she responds to."

create_a_every_action_contribution

Allows the AI agent to process or log a new contribution payment against a contact record.

Contextual usage notes: This is a high-stakes write operation. The schema requires the contact, designation, gatewayId, amount (between $0.01 and $999,999.99), and paymentMethod. It strictly validates financial inputs before hitting the EveryAction API.

"Log a new contribution of $500 for VAN ID 1048573. Apply it to the Q4 Digital Fundraising designation and use the standard gateway ID."

get_single_every_action_activist_code_by_id

Activist codes are the backbone of field organizing, used to tag voters or volunteers with specific attributes (e.g., 'Yard Sign Request', 'Strong Supporter').

Contextual usage notes: Requires the ID of the activist code. It returns the script question, description, and status, allowing the LLM to understand the context of a code before applying it in bulk operations.

"Look up the details for Activist Code ID 45892. What is the script question associated with this code?"

list_all_every_action_printed_lists

Retrieves available Printed Lists (turfs) used for door-to-door canvassing and field operations.

Contextual usage notes: Can be filtered by creator, folder, or generation date. Returns the list size and event signups. Excellent for agents acting as automated field directors assigning turf to canvassers.

"List all the printed lists generated this week in the 'Weekend GOTV' folder. Tell me the total list size for the largest turf."

create_a_every_action_voter_registration_batch

Allows the agent to programmatically add new registrants to a Voter Registration Batch.

Contextual usage notes: Requires a batch_id. Accepts up to 25 registrants per request as a bare JSON array. Essential for field operations that digitize paper registration forms via OCR and need to push the data into EveryAction.

"I have five new voter registrations extracted from yesterday's field forms. Push them into Voter Registration Batch ID 9923."

create_a_every_action_bulk_import_job

Initiates a massive data import, commonly used for loading external scores, fresh voter data, or cross-referenced contact lists.

Contextual usage notes: The zipped file must be hosted securely (HTTPS/SFTP) and be under 20 MB. The agent must map the actions schema correctly to dictate how the CSV columns align with EveryAction entities.

"Create a bulk import job to update our Contacts with the newly generated turnout scores. The zipped CSV is hosted at our secure S3 URL. Map column A to VAN ID and column B to custom score field 4."

To view the complete schema details, JSON mappings, and the full inventory of available endpoints, visit the EveryAction integration page.

Workflows in Action

When you connect Claude to EveryAction using an MCP server, you transform a static LLM into an active participant in your campaign or nonprofit infrastructure. Here are two concrete workflows demonstrating how an agent orchestrates multi-step processes.

Workflow 1: The Automated Donor Briefing

Major gifts officers spend hours compiling research before calling a high-net-worth donor. An AI agent can automate this instantly.

"Claude, prepare a call briefing for Michael Smith (msmith@example.com). Find his record, list his lifetime contributions, and summarize his giving history."

Step-by-step execution:

1. Identity Resolution: Claude calls every_action_people_search passing the email address to retrieve Michael's exact vanId and his custom biographical properties (occupation, employer).
2. Financial Audit: Claude calls list_all_every_action_contributions using the retrieved vanId. The MCP router strictly maps the LLM's arguments to the EveryAction query schema.
3. Synthesis: Claude receives the paginated list of contributions, synthesizes the total giving amount, identifies his preferred donation channels (source codes), and outputs a clean, markdown-formatted briefing document for the gifts officer.

sequenceDiagram
    participant User as User Prompt
    participant Claude as "Claude Desktop"
    participant Truto as "Truto MCP Server"
    participant EA as "EveryAction API"
    
    User->>Claude: "Prepare call briefing for msmith@example.com"
    Claude->>Truto: call tools/call (every_action_people_search)
    Truto->>EA: GET /people?email=msmith@example.com
    EA-->>Truto: Returns vanId 882194
    Truto-->>Claude: JSON Tool Result
    Claude->>Truto: call tools/call (list_all_every_action_contributions)
    Truto->>EA: GET /contributions?vanId=882194
    EA-->>Truto: Returns donation history
    Truto-->>Claude: JSON Tool Result
    Claude-->>User: Generates formatted Donor Briefing Document

Workflow 2: Field Turf Analysis and Volunteer Assignment

Field directors need to rapidly assess the scale of their weekend canvassing operations and assign turfs based on list size.

"Claude, analyze our current field operations. Pull all printed lists from the 'Saturday GOTV' folder, look up the activist code we are using to mark positive IDs, and tell me how many doors we are knocking this weekend."

Step-by-step execution:

1. Turf Retrieval: Claude calls list_all_every_action_printed_lists, applying a filter for the specific folder name. It receives an array of lists, aggregating the listSize parameter across all active turfs.
2. Context Gathering: Claude calls get_single_every_action_activist_code_by_id (using the ID it knows from system context) to verify the script question volunteers will be asking at the doors.
3. Reporting: Claude returns a comprehensive operational report detailing the total number of doors to knock, the specific turfs available, and a reminder of the script the volunteers will use.

Wrapping Up

Integrating Claude with EveryAction unlocks a massive competitive advantage for nonprofits, advocacy groups, and political campaigns. By utilizing an MCP server, you eliminate the friction of manually exporting CSVs and digging through complex CRM interfaces.

However, building this infrastructure internally requires managing complex OAuth flows, handling EveryAction's OData-style queries, and constantly updating custom code when endpoints change. Truto abstracts this completely. By dynamically generating documentation-driven tools, standardizing authentication, and passing rate limit headers transparently, Truto allows your engineering team to focus on building intelligent agent behaviors rather than maintaining brittle API plumbing.