Connect Lightfield to Claude: Sync Emails, Tasks, and Meetings

If you need to connect Lightfield to Claude to automate CRM workflows, draft emails, sync meetings, or manage custom business objects, you need a Model Context Protocol (MCP) server. This server acts as the translation layer between Claude's natural language tool calls and Lightfield'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 Lightfield to ChatGPT or explore our broader architectural overview on connecting Lightfield to AI Agents.

Giving a Large Language Model (LLM) read and write access to a complex CRM and productivity suite like Lightfield is an engineering challenge. You have to handle dynamic entity schemas, map complex JSON payloads to MCP tool definitions, and deal with Lightfield's strict data privacy model. Every time a RevOps admin adds a custom field or changes an object relationship, your server code must adapt instantly.

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

The Engineering Reality of the Lightfield 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 specialized B2B APIs is painful. Lightfield is built to be a highly customizable system of record, and its API design reflects that complexity.

If you decide to build a custom Lightfield MCP server, here are the specific integration challenges you will face:

System Fields vs Custom Fields (The $ Prefix) Lightfield does not use a flat data structure for records. System-defined fields are strictly prefixed with a $ (e.g., $name, $howTheyMakeMoney, $accountStatus), while custom fields created by users lack this prefix. Furthermore, some system fields are complex objects rather than strings. For example, a contact's $name is not a string but an object requiring { firstName, lastName }. An LLM has no intuition for this. It will naturally try to pass name: "John Doe" and trigger a 400 Bad Request. Your MCP server must expose schema definition tools (get_definitions) so the LLM can dynamically inspect the expected payload structures before executing a write operation.

Privacy Redaction and Silent 404s Lightfield enforces strict access control at the record and field level. Endpoints like get_single_lightfield_meeting_by_id or get_single_lightfield_email_by_id dynamically redact data based on the caller's privacy resolution. The API returns a read-only accessLevel field and simply strips out restricted data (like transcripts or message bodies) rather than throwing an explicit unauthorized error. Even trickier, if you query a private channel that the authenticated user is not a member of, Lightfield returns a 404 Not Found instead of a 403 Forbidden. Your agent logic must account for data that simply "disappears" based on the token context.

Soft-Delete State Machines When you delete a record in Lightfield, it is not actually destroyed. The API relies on soft-deletes, moving items to a "trash" state. Calling a delete endpoint on an already-trashed record is a silent no-op. If your agent needs to audit deleted records, standard list endpoints will hide them by default. You have to explicitly pass status=trashed to list endpoints, and use dedicated restore endpoints to bring them back. This requires exposing highly specific tool parameters to the LLM to manage record states correctly.

Generating the Lightfield MCP Server

Instead of building a translation layer from scratch, Truto dynamically generates an MCP server directly from your connected Lightfield instance. This server maps Lightfield's resources into MCP-compliant JSON-RPC tools instantly.

You can generate this server in two ways: via the Truto UI or programmatically via the API.

Method 1: Via the Truto UI

For internal tooling and testing, the UI is the fastest path:

1. Log into your Truto dashboard and navigate to the integrated account page for your Lightfield connection.
2. Click the MCP Servers tab.
3. Click Create MCP Server.
4. Select your desired configuration. You can restrict the server to specific HTTP methods (e.g., read only) or specific resource tags.
5. Copy the generated MCP server URL (e.g., https://api.truto.one/mcp/a1b2c3d4e5f6...).

Method 2: Via the Truto API

For production multi-tenant applications, you generate MCP servers programmatically for each of your customers. Make an authenticated POST request to the Truto API:

curl -X POST https://api.truto.one/integrated-account/{integrated_account_id}/mcp \
  -H "Authorization: Bearer YOUR_TRUTO_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "name": "Lightfield RevOps Agent",
    "config": {
      "methods": ["read", "write", "custom"]
    }
  }'

The API returns a secure, unique URL for this specific Lightfield instance:

{
  "id": "mcp-789-xyz",
  "name": "Lightfield RevOps Agent",
  "config": { "methods": ["read", "write", "custom"] },
  "expires_at": null,
  "url": "https://api.truto.one/mcp/a1b2c3d4e5f6..."
}

Connecting the MCP Server to Claude

Once you have your Truto MCP URL, you can connect it to Claude in seconds. The MCP server URL is fully self-contained; the cryptographic token in the URL handles authentication back to Truto and Lightfield.

Method A: Via the Claude UI (Claude Desktop or Web)

If you are using Claude Desktop or the Claude web interface with custom connector support:

1. Open Claude and navigate to Settings -> Integrations (or Connectors).
2. Click Add MCP Server or Add custom connector.
3. Give the connector a name (e.g., "Lightfield API").
4. Paste the Truto MCP URL into the connection field.
5. Click Add. Claude will instantly connect to Truto, handshake via the initialize method, and load the available Lightfield tools.

Method B: Via the claude_desktop_config.json File

For local development and automated provisioning, you can configure Claude Desktop manually by editing its configuration file.

Open your claude_desktop_config.json file (typically found in ~/Library/Application Support/Claude/ on macOS or %APPDATA%\Claude\ on Windows) and add the Server-Sent Events (SSE) transport configuration:

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

Restart Claude Desktop. The application will execute the remote SSE connection, and you will see the Lightfield tools available via the plug icon in the chat interface.

Hero Tools for Lightfield

When connected, Claude gains access to the complete surface area of the Lightfield API. Here are the most powerful operations your agent can now perform.

1. lightfield_opportunities_get_definitions

Because Lightfield allows extreme customization of object schemas, LLMs must inspect the schema before writing data. This tool returns the field and relationship definitions available on opportunities, covering both system-defined ($) and custom fields.

"Inspect the schema for Lightfield opportunities. I need to know the exact field keys for the deal amount and closing date, and whether they are system fields or custom fields before we create a new record."

2. create_a_lightfield_opportunity

Creates a new opportunity record. The agent uses this after discovering the correct schema. It requires the $name field and an $account relationship. Lightfield handles the opportunity summary generation in the background automatically.

"Create a new opportunity called 'Acme Corp Q4 Expansion'. Link it to the account ID 'acc_9876' and set the custom field 'deal_stage' to 'Discovery'."

3. lightfield_enrichment_runs_enrich

Triggers an asynchronous background job to enrich a contact or account. Lightfield looks up missing field values from integrated data providers and writes them back to the record. The tool returns a run ID that the agent can poll to check the status.

"Start an enrichment run for contact ID 'con_1234'. Check the status of the run, and once it completes, read the updated profile to see if their job title and LinkedIn URL were populated."

4. lightfield_emails_draft

Creates a draft email in the connected Lightfield mailbox that owns the from address. This is incredibly powerful for AI SDR workflows, allowing the LLM to write highly contextual emails without sending them immediately.

"Draft an email from my address to 'jane.doe@example.com'. The subject should be 'Following up on our workflow discussion'. Write a brief, professional message referencing the notes from our last meeting, and leave it in my drafts for review."

5. get_single_lightfield_meeting_by_id

Retrieves the details of a meeting, including the transcript if the caller has the correct privacy access level. This allows the LLM to summarize past interactions before drafting follow-ups or updating CRM records.

"Fetch the meeting with ID 'mtg_555'. If the transcript is available and not redacted by privacy settings, summarize the key action items and list any new stakeholders mentioned."

6. create_a_lightfield_object

Lightfield's extensibility comes from custom objects. This tool allows the LLM to create records for custom entities by specifying the entity_slug and providing the required fields based on the custom schema.

"We just signed a new vendor agreement. Create a new record in the custom 'contracts' object (slug: 'custom_contract_obj'). Set the contract value to 50000 and link it to account 'acc_444'."

For the complete list of available tools, including tasks, merges, webhook configurations, and file handling endpoints, view the Lightfield integration page.

Workflows in Action

With these tools exposed to Claude, you can build autonomous workflows that bridge the gap between communication and CRM data entry.

Scenario 1: Post-Meeting Deal Execution

Account Executives spend hours summarizing calls and updating the CRM. An AI agent can handle this entire post-meeting workflow autonomously.

"Review the transcript for my recent meeting with Acme Corp (mtg_891). Summarize the discussion, update the contact's job title using an enrichment run if we don't have it, create a new opportunity for the discussed expansion, and draft a follow-up email thanking them for their time."

Execution Steps:

1. get_single_lightfield_meeting_by_id: Claude retrieves the meeting transcript and parses the action items.
2. lightfield_enrichment_runs_enrich: Claude triggers an enrichment on the contact to pull their latest title, polling get_single_lightfield_enrichment_run_by_id until complete.
3. lightfield_opportunities_get_definitions: Claude checks the required schema for opportunities to ensure it structures the payload correctly.
4. create_a_lightfield_opportunity: Claude creates the deal, setting the $name and linking the $account.
5. lightfield_emails_draft: Claude drafts a highly contextual follow-up email based on the transcript and leaves it in the user's outbox for review.

Scenario 2: Autonomous Custom Object Ingestion

RevOps teams frequently use custom objects to track specialized data like "Hardware Deployments" or "Support Escalations." AI agents can navigate these custom schemas without hardcoded logic.

"A customer just approved their hardware rollout plan. Inspect the custom object 'hardware_deployments'. Figure out what fields are required, then create a new deployment record for account 'acc_102' scheduled for next Tuesday."

sequenceDiagram
    participant User
    participant Claude as Claude Desktop
    participant MCP as Truto MCP Server
    participant Upstream as Lightfield API

    User->>Claude: "Create deployment for acc_102"
    Claude->>MCP: Call lightfield_object_types_get_definitions (slug: hardware_deployments)
    MCP->>Upstream: Proxy GET request
    Upstream-->>MCP: Returns custom schema (fieldDefinitions)
    MCP-->>Claude: Schema details
    Note over Claude: Claude analyzes schema<br>to map user intent to required fields
    Claude->>MCP: Call create_a_lightfield_object (slug, fields map)
    MCP->>Upstream: Proxy POST request
    Upstream-->>MCP: 201 Created (Record ID)
    MCP-->>Claude: Custom object created
    Claude-->>User: "Deployment scheduled successfully."

Execution Steps:

1. lightfield_object_types_get_definitions: Claude fetches the custom entity schema to learn the exact field names (e.g., deployment_date, hardware_type).
2. create_a_lightfield_object: Claude constructs the correct JSON payload dynamically and creates the record.
3. Claude responds to the user confirming the successful data entry, navigating the custom architecture seamlessly.

Rate Limits and Pagination Architecture

When building autonomous agents, handling API limits is critical. Truto does not retry, throttle, or apply backoff on rate limit errors.

When Lightfield returns an HTTP 429 Too Many Requests, Truto passes that error directly to the caller. However, Truto normalizes the upstream rate limit information into standardized IETF headers across all endpoints:

• ratelimit-limit
• ratelimit-remaining
• ratelimit-reset

Your MCP client architecture is responsible for reading these headers and implementing its own retry and backoff logic. Furthermore, for endpoints that return lists (like list_all_lightfield_contacts), Truto automatically injects limit and next_cursor parameters into the tool's JSON Schema. The description explicitly instructs the LLM to pass the cursor value back unchanged on subsequent calls, allowing Claude to paginate through large datasets naturally.

Security and Access Control

Giving an LLM access to your CRM requires strict boundaries. Truto MCP servers provide four key security controls configurable at creation time:

• Method Filtering: Use the config.methods array to restrict operations. Passing ["read"] ensures the LLM can only query data, while passing ["custom"] limits it to non-CRUD operations like search or enrichment.
• Tag Filtering: Use config.tags to restrict access to specific resource groups. For example, filtering by ["support"] might expose only ticketing tools while hiding financial records.
• Authentication Layering: Setting require_api_token_auth: true ensures that possession of the MCP URL alone is not enough. The connecting client must also supply a valid Truto API token in the Authorization header, preventing anonymous access if the URL leaks.
• Ephemeral Servers: The expires_at field allows you to create temporary MCP servers. Once the ISO timestamp passes, the server self-destructs, making it perfect for short-lived agentic tasks or contractor access.

Build the ultimate RevOps agent

Connecting Lightfield to Claude via Truto's managed MCP architecture removes the pain of integrating dynamic schemas, handling complex authentication, and parsing non-standard JSON responses. Instead of writing and maintaining hundreds of lines of brittle API connection code, you provide your AI with a secure, auto-updating bridge directly to your system of record.

Ready to get started? Generate your first MCP server in minutes and give your agents the context they need to do real work.