Connect dotloop to Claude: Sync Real Estate Contacts and Activities

If your real estate brokerage needs to connect dotloop to Claude to automate compliance checks, synchronize client contacts, or oversee transaction activities, you need a Model Context Protocol (MCP) server. This server acts as the translation layer between Claude's function calls and dotloop's REST APIs. 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 /connect-dotloop-to-chatgpt-manage-transaction-loops-and-documents/ or explore our broader architectural overview on /connect-dotloop-to-ai-agents-automate-closing-tasks-and-folders/.

Giving a Large Language Model (LLM) read and write access to a sprawling transaction management ecosystem like dotloop is an engineering challenge. You have to handle OAuth 2.0 token lifecycles, map dotloop's deeply nested property schemas to MCP tool definitions, and manage strict hierarchical data dependencies (like profiles to loops to folders). Every time dotloop updates an endpoint, you have to update your server code, redeploy, and test the integration.

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

The Engineering Reality of the dotloop 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. dotloop is built to manage complex real estate transactions across multiple brokerages, teams, and individuals. Its API reflects that complexity.

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

Strict Profile-Based Isolation You cannot simply query "all loops" across a user's account. In dotloop, every transaction loop, document, and contact belongs to a specific profile_id. A user can be part of multiple profiles (e.g., their personal agent profile, their team profile, and the brokerage profile). Your LLM cannot guess this profile_id. Your MCP server must expose operations that explicitly require the profile_id in the query schema, or you must build a caching layer that maps active sessions to default profiles before executing requests.

Nested and Spaced Field Names in Loop Details When you interact with the dotloop_loop_details_bulk_update or retrieval endpoints, dotloop returns data grouped by sections (like "Financials" or "Property Address") using dotloop's own field names. These field names often contain spaces (e.g., "Street Name", "Purchase Price"). Standardizing this for an LLM that expects camelCase or snake_case JSON schemas is difficult. Truto handles this natively by preserving dotloop's schema and providing explicit tool descriptions so Claude knows exactly how to format the nested payload, such as {"Property Address": {"Street Name": "123 Main St"}}.

File Handling and Multipart Forms Uploading documents to a transaction folder is not a simple JSON POST request. It requires a multipart/form-data payload where the PDF binary is sent as a file part, and the file name dictates the resulting document name in dotloop. Building an MCP server that reliably accepts binary inputs or file paths from a local Claude Desktop instance and pipes them into a multipart HTTP request requires custom transport logic.

Raw Rate Limit Exposure dotloop enforces strict API quotas. When you hit a rate limit, the API returns an HTTP 429 status. It is critical to note that Truto does not retry, throttle, or apply backoff on rate limit errors. When dotloop returns a 429, Truto passes that error directly to the caller, while normalizing the upstream rate limit info into standardized headers (ratelimit-limit, ratelimit-remaining, ratelimit-reset) per the IETF spec. The caller (in this case, your custom Claude client script or orchestrator) is fully responsible for handling the retry and backoff logic.

Generating the dotloop MCP Server

Truto dynamically generates MCP tools based on the resources available in the connected dotloop account. You can spin up this server via the Truto UI or programmatically via the API.

Method 1: Via the Truto UI

For teams testing workflows or deploying internal tools, the UI provides a fast path to an MCP server URL.

1. Log into your Truto dashboard and navigate to the integrated account page for your dotloop connection.
2. Click the MCP Servers tab.
3. Click Create MCP Server.
4. Select your desired configuration (e.g., limit to read-only methods, set an expiration date, or require API token auth).
5. Copy the generated MCP server URL. It will look like https://api.truto.one/mcp/a1b2c3d4e5f6....

Method 2: Via the Truto API

For production use cases where you are provisioning agents on behalf of your customers, you can generate the MCP server programmatically.

Make a POST request to /integrated-account/:id/mcp:

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

The response will contain the secure MCP URL that you will pass to Claude.

Connecting the dotloop MCP Server to Claude

Once you have your Truto MCP URL, connecting it to Claude is a one-step configuration process. You can do this via the UI or by editing the Claude Desktop configuration file.

Method 1: Via the Claude UI

If you are using Claude for Web or Enterprise:

1. Navigate to Settings -> Integrations -> Add MCP Server.
2. Paste your Truto MCP server URL.
3. Click Add. Claude will instantly execute the MCP initialization handshake and discover all available dotloop tools.

Method 2: Via Manual Configuration File

If you are running Claude Desktop locally and want to connect via Server-Sent Events (SSE), edit your claude_desktop_config.json file.

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

Restart Claude Desktop. The dotloop tools will now be available in the prompt interface.

Hero Tools for dotloop Automation

Truto automatically generates highly specific tools derived from dotloop's API documentation. Here are the highest-leverage operations your agent can use.

Get Account Details (list_all_dotloop_account)

Before taking action on loops, the agent must determine the connected user's defaultProfileId. This tool retrieves the core account details needed for all subsequent routing.

"Fetch my dotloop account details and tell me my default profile ID. We will use this ID for all transaction tasks today."

Create a Loop (create_a_dotloop_loop)

Initializes a new transaction loop. This is the foundational object in dotloop. It requires the profile_id obtained from the account details tool.

"Create a new dotloop transaction loop named '123 Fake Street - Sale' under my default profile ID."

Get Loop Details (get_single_dotloop_loop_detail_by_id)

Retrieves the deeply nested metadata for a specific loop. The response is grouped by sections with dotloop's native spaced field names (e.g., "Property Address" -> "Street Name").

"Pull the detailed records for loop ID 45892 in my profile. Extract the purchase price from the Financials section and the street name from the Property Address section."

Add a Loop Participant (create_a_dotloop_loop_participant)

Adds a buyer, seller, or co-op agent to a specific transaction loop. This requires the profile_id, the loop_id, and their specific role.

"Add Jane Doe as a Buyer participant to loop ID 45892. Her email is jane@example.com and her role is 'BUYER'."

Upload a Document (create_a_dotloop_loop_document)

Uploads a binary file (like a PDF) to a specific folder within a loop. The MCP router handles the multipart form-data assembly, requiring the profile_id, loop_id, folder_id, and the file payload.

"Upload this signed agency disclosure PDF to folder ID 99281 in loop 45892. Name the document 'Agency_Disclosure_Signed'."

List all Loop Tasks (list_all_dotloop_loop_tasks)

Retrieves all task items within a specific task list. This is critical for compliance and closing coordination, allowing the LLM to audit what signatures or documents are missing.

"List all tasks in the 'Closing Checklist' task list for loop 45892. Identify any tasks that are not yet marked complete."

To view the complete inventory of available dotloop endpoints, query parameters, and schema requirements, check out the dotloop integration page.

Workflows in Action

By chaining these tools together, Claude can execute multi-step real estate operations autonomously.

Scenario 1: New Listing Intake Automation

When an agent secures a new listing, Claude can parse the intake notes, set up the entire dotloop infrastructure, and invite the sellers.

"I just signed a new listing for 555 Oak Lane with John Smith (john@example.com). Set up the loop in my default profile, add John as a Seller, and upload this listing agreement draft to the main folder."

Execution Steps:

1. list_all_dotloop_account: Claude retrieves the user's defaultProfileId.
2. create_a_dotloop_loop: Claude creates the "555 Oak Lane" loop and captures the new loop_id.
3. list_all_dotloop_loop_folders: Claude lists folders in the new loop to find the ID of the default main folder.
4. create_a_dotloop_loop_participant: Claude adds John Smith with the role SELLER to the loop.
5. create_a_dotloop_loop_document: Claude uploads the listing agreement file to the target folder.

sequenceDiagram
    participant User as Agent User
    participant Claude as Claude Desktop
    participant Truto as Truto MCP Server
    participant dotloop as dotloop API

    User->>Claude: "Set up listing for 555 Oak Lane..."
    Claude->>Truto: list_all_dotloop_account()
    Truto->>dotloop: GET /profile
    dotloop-->>Truto: profile_id
    Truto-->>Claude: profile_id
    
    Claude->>Truto: create_a_dotloop_loop(profile_id, name)
    Truto->>dotloop: POST /profile/{id}/loop
    dotloop-->>Truto: loop_id
    Truto-->>Claude: loop_id
    
    Claude->>Truto: create_a_dotloop_loop_participant(profile_id, loop_id, John Smith)
    Truto->>dotloop: POST /profile/{id}/loop/{id}/participant
    dotloop-->>Truto: participant_id
    Truto-->>Claude: Success

Scenario 2: Pre-Closing Compliance Audit

Brokerage admins spend hours reviewing files before authorizing commissions. Claude can perform a first-pass audit on a transaction.

"Audit loop ID 88472. Check the loop details to ensure the purchase price is entered. Then check the 'Compliance Review' task list and tell me if any tasks are missing."

Execution Steps:

1. list_all_dotloop_account: Claude fetches the profile_id.
2. get_single_dotloop_loop_detail_by_id: Claude pulls the deeply nested loop details, parsing the "Financials" section to verify the "Purchase Price" field is populated.
3. list_all_dotloop_loop_task_lists: Claude finds the task_list_id for "Compliance Review".
4. list_all_dotloop_loop_tasks: Claude fetches the individual items on the checklist and identifies incomplete tasks, summarizing the missing requirements for the admin.

Security and Access Control

Exposing an entire transaction management system to an LLM requires strict boundary setting. Truto MCP servers support multiple layers of programmatic access control:

• Method Filtering: You can restrict an MCP server to read-only operations by passing "methods": ["read"] during creation. This ensures Claude can audit loops and task lists, but cannot delete contacts or modify loop participants.
• Tag Filtering: If dotloop resources are tagged in your Truto configuration (e.g., "tags": ["loops", "tasks"]), you can restrict the server to only those specific tool groups.
• Time-To-Live (expires_at): You can assign an ISO datetime for the MCP server to self-destruct. This is ideal for granting a temporary auditing agent access to a brokerage account during end-of-month reconciliation.
• API Token Auth (require_api_token_auth): By default, possessing the MCP URL grants access to the tools. Enabling this flag forces the client to also pass a valid Truto API token in the Authorization header, adding a required secondary authentication layer.

Move Beyond Integration Maintenance

Building a custom MCP server for dotloop means taking ownership of OAuth token refreshes, profile ID routing, multipart file handling, and nested schema normalization. Every time you need a new tool, you have to write the handler, map the schema, and redeploy.

By leveraging Truto, your MCP tools are dynamically generated directly from the dotloop API documentation. You get secure, real-time access to real estate transaction data, completely decoupled from infrastructure maintenance. Your engineers can focus on building intelligent AI capabilities, not managing third-party REST payloads.