Skip to content

MCP Tool Integration

Preloop is an MCP-native policy engine. It exposes an MCP endpoint to AI clients, but it does more than a normal MCP server: it evaluates policies before any tool call reaches the underlying tool.

What MCP Means In Preloop

MCP gives AI clients a standard way to:

  • discover tools
  • inspect tool schemas
  • call those tools

Without Preloop, the flow is simple:

AI client -> MCP server -> tool executes

With Preloop, there is a policy decision in the middle:

AI client -> Preloop MCP endpoint -> policy evaluation -> allow / deny / require approval

That is why Preloop is better described as a Safety Layer than as a plain MCP proxy.

MCP Endpoint And Transport

Preloop serves its MCP endpoint at:

https://YOUR_PRELOOP_URL/mcp/v1

The current MCP integration is streamable HTTP.

Use standard HTTP MCP client configuration such as:

claude mcp add \
  --transport http \
  --header "Authorization: Bearer YOUR_API_KEY" \
  preloop \
  https://YOUR_PRELOOP_URL/mcp/v1

This page intentionally does not document stdio transport because the current product architecture and product docs center on the hosted/self-hosted HTTP MCP endpoint.

What Happens On A Tool Call

When an MCP client calls a tool through Preloop, the request goes through four stages:

  1. Authentication The MCP client connects with an API key.

  2. Tool filtering Preloop exposes only the tools the current user should see.

  3. Policy evaluation Ordered access rules decide whether the call should be allowed, denied, or routed to approval.

  4. Execution or approval handling Allowed calls execute immediately. Approval-gated calls wait for the configured workflow. Denied calls return a clear error.

sequenceDiagram
    participant Client as MCP Client
    participant Preloop as Preloop
    participant Policy as Access Rules
    participant Workflow as Approval Workflow
    participant Tool as Target Tool

    Client->>Preloop: tools/call(...)
    Preloop->>Policy: Evaluate ordered rules

    alt allow
        Policy->>Tool: Execute
        Tool-->>Preloop: Result
        Preloop-->>Client: Result
    else deny
        Policy-->>Preloop: Deny with message
        Preloop-->>Client: Error
    else require approval
        Policy->>Workflow: Create approval request
        Workflow-->>Preloop: Pending / approved / declined
        Preloop-->>Client: Blocking or async response
    end

Built-In Tools And External MCP Servers

Preloop can expose two kinds of tools through the same MCP endpoint.

Built-In Tools

These are tools provided by Preloop itself.

Examples include:

  • approval helpers such as request_approval
  • async approval polling such as get_approval_status
  • built-in product tools that appear when the related integrations are configured

The exact built-in tool set is dynamic, so the safest mental model is:

  • some tools are always available because Preloop owns them
  • others appear only when the relevant Preloop feature or integration is enabled

External MCP Tools

Preloop can also proxy tools from MCP servers you add in Tools & MCP.

That means the same client connection can expose:

  • Preloop-owned built-in tools
  • tools discovered from external MCP servers

Both categories can be governed by the same access rules and approval workflows.

Dynamic Tool Filtering

The tool list returned over MCP is not static.

Preloop filters tools based on:

  • the current authenticated user
  • account roles and permissions
  • enabled integrations
  • configured external MCP servers
  • per-tool enablement and policy configuration

This is important operationally: the MCP client only sees the tools that are available and appropriate for that user and account state.

Blocking Approval vs Async Approval

Preloop supports two approval patterns for MCP tool calls.

Blocking Approval

The tool call waits while the approval workflow runs.

Use this when:

  • the client can tolerate a longer call
  • you want the final tool result in the same interaction

Async Approval

The tool call returns immediately with a pending approval state and a request identifier. The client or agent then polls get_approval_status until the approval decision is made and the tool result is available.

Use this when:

  • the client should not hold a long-lived request open
  • you want approval to fit better into agent loops

request_approval vs Policy-Gated Tools

There are two related but different approval patterns in Preloop:

Policy-Gated Tool

An existing tool is protected by access rules. The agent calls the tool normally, and Preloop decides whether approval is required.

request_approval

The agent explicitly asks for approval as a deliberate step in its workflow before doing something else.

This is useful when:

  • the action spans multiple steps
  • the agent wants to provide richer context first
  • approval timing should be controlled by the workflow, not just by a tool rule

Why MCP Works Well With Preloop

MCP gives you a standard tool interface. Preloop adds the missing control plane:

  • policy enforcement before execution
  • approval workflows for risky actions
  • auditability across tool use
  • consistent access control across built-in and external tools

That is what makes Preloop an MCP-native Safety Layer rather than just another MCP endpoint.