Provider-Backed MCP Bindings

Use this guide when you want one handle to expose MCP tools backed by an external HTTPS API. A provider-backed binding is still a 10x function binding, but its runtime target is an external provider endpoint instead of a built-in template or published skill runtime.

This is the right pattern when you already have a stable HTTPS API and you want 10x hosted MCP to surface it as one or more handle-scoped tools.

If the goal is to install a UI plugin that runs inside the local OpenAnalyst runtime, use Custom OpenAnalyst Plugin Setup instead. Provider-backed bindings expose hosted MCP tools; they do not install local OpenAnalyst plugin apps.

What provider-backed bindings support now

Current provider bindings support:

• target.type = "provider"
• authenticated MCP only
• sync execution only
• https:// upstream endpoints only
• manually defined tool.name, description, and inputSchema
• operator-defined tool behavior metadata
• provider auth modes none, bearer_secret_ref, and header_secret_ref

Current provider bindings do not support:

• public browser or WebMCP discovery through /_fn/*
• async execution
• auto-discovery of upstream MCP tools
• streamable HTTP, SSE, or generic MCP message passthrough

When to use provider vs template vs skill

Source-of-truth contract

Provider-backed bindings are created through:

• POST /v2/handles/{handle}/function-bindings

Provider-backed MCP invocation happens through:

• POST /v2/public/handles/{handle}/function-bindings/{bindingKey}/invoke

Provider rules in the current implementation:

• exposure.authenticatedMcp must be true
• exposure.publicWeb must be false
• execution.mode must be "sync"
• target.endpointUrl must be https://...
• config.method must be GET or POST
• config.timeoutMs is clamped to 1000..10000
• config.auth.mode can be:
• none
• bearer_secret_ref
• header_secret_ref

Request shaping is intentionally narrow:

• GET turns the validated MCP payload into query parameters
• POST sends the validated MCP payload as JSON

Response shaping is also narrow:

• JSON responses are returned as JSON in the hosted MCP sync envelope
• non-JSON responses are returned as text in the sync envelope
• upstream 4xx and 5xx responses are still normalized into a sync tool result with ok: false

Operator workflow

1. Prepare the upstream API

   Make sure the upstream is reachable at a stable https:// URL and returns synchronous JSON or text responses. If the upstream needs authentication, store that secret as a platform-managed secret and note the secret name you will reference in the binding.

2. Create the provider binding

   In https://app.10x.in, open the handle and go to Integrations -> MCP & Tools. In the Save Binding form:

   • set Target type to provider
   • enter the provider Endpoint URL
   • choose Provider method
   • set Provider timeout (ms)
   • choose Provider auth mode
   • add Secret name and Header name when required
   • set Tool name, description, and input schema
   • confirm the behavior hints

   The UI forces provider bindings to authenticated MCP only and sync only.

3. Confirm tool behavior metadata

   Provider bindings are exposed to MCP clients using the tool metadata you define locally. In the current UI, switching to provider resets the default behavior hints to:

   • operationClass = write
   • openWorld = true
   • idempotent = false

   If you create bindings through the API instead of the UI, send the equivalent tool.behavior object explicitly.

4. Expose the binding through MCP Builder

   In the same Integrations -> MCP & Tools surface, use MCP Builder to verify that the binding is visible on the hosted MCP connector for that handle.

5. Connect an MCP client

   Connect the handle MCP endpoint such as https://{handle}.mcp.10x.in/mcp and make sure the client has:

   • mcp.connect
   • binding.invoke:{bindingKey} for the provider-backed binding you want to call

6. Invoke the tool

   Ask the MCP client to run the tool by the tool.name you configured. The hosted MCP transport validates the input against your declared schema, then invokes the provider endpoint using the configured method and auth mode.

Example binding payload

This example exposes one external flight-search endpoint as the hosted MCP tool search_flights:

{
  "bindingKey": "flight_search",
  "status": "ACTIVE",
  "target": {
    "type": "provider",
    "endpointUrl": "https://travel-adapter.example.com/search-flights"
  },
  "exposure": {
    "publicWeb": false,
    "authenticatedMcp": true
  },
  "execution": {
    "mode": "sync"
  },
  "tool": {
    "name": "search_flights",
    "description": "Search flights for one departure date with optional filters.",
    "behavior": {
      "operationClass": "write",
      "mutatesState": true,
      "openWorld": true,
      "idempotent": false,
      "sensitivity": "standard"
    }
  },
  "inputSchema": {
    "type": "object",
    "properties": {
      "origin": { "type": "string" },
      "destination": { "type": "string" },
      "departure_date": { "type": "string" },
      "return_date": { "type": "string" },
      "cabin_class": { "type": "string" },
      "max_stops": { "type": "string" },
      "departure_window": { "type": "string" },
      "airlines": {
        "type": "array",
        "items": { "type": "string" }
      },
      "sort_by": { "type": "string" },
      "passengers": { "type": "integer" }
    },
    "required": ["origin", "destination", "departure_date"]
  },
  "config": {
    "method": "POST",
    "timeoutMs": 8000,
    "auth": {
      "mode": "bearer_secret_ref",
      "secretName": "/10x-dot-in/prod/providers/fli/api-token"
    }
  }
}

Fli example: the supported pattern today

Fli is a Python flight-search package that also exposes:

• fli-mcp for STDIO MCP
• fli-mcp-http for HTTP MCP

Fli's MCP tool surface is:

• search_flights
• search_dates

The important boundary is that 10x provider bindings do not consume upstream MCP discovery or message transport directly. Pointing a provider binding at fli-mcp-http does not make 10x import Fli's tools automatically.

Recommended Fli pattern in 10x today

Host a thin HTTPS JSON adapter in front of Fli, then expose that adapter through two provider-backed bindings.

Recommended adapter routes:

• POST /search-flights
• POST /search-dates

Recommended local 10x bindings:

Minimum adapter requirements:

• reachable at a stable https:// URL
• synchronous JSON request and response behavior
• request schema aligned to the local binding inputSchema
• response body shaped for the MCP client you expect to use
• optional auth that can be expressed as bearer_secret_ref or header_secret_ref

Example adapter request shape

For search_flights, the adapter can accept the same object that the binding schema exposes:

{
  "origin": "JFK",
  "destination": "LHR",
  "departure_date": "2026-10-25",
  "cabin_class": "BUSINESS",
  "max_stops": "NON_STOP",
  "sort_by": "CHEAPEST",
  "passengers": 1
}

The adapter is responsible for translating that JSON into the real Fli call and returning a stable response. 10x does not transform provider bindings into upstream MCP requests.

When not to use provider for Fli

If the goal is to use Fli as a native MCP server directly, connect fli-mcp or fli-mcp-http to the MCP client instead of routing it through 10x provider bindings. That path keeps the MCP transport native to Fli and avoids building an HTTP adapter.

Pairing with Context Store

Provider-backed bindings and Context Store solve different parts of a connector workflow:

Do not put provider credentials or arbitrary provider secret names into Context Store source config. Keep those credentials in provider/function-binding auth, then let agents choose the execution path:

• context_store_search when source/entity status is READY or PREVIEW
• provider-backed binding invocation for writes, missing entities, or real-time reads

See Context Store Connectors for source setup examples.

Troubleshooting

Related guides

• Apps and MCP Tools
• Hosted Tools & Skills Invocation
• MCP Builder and Hosted Tools
• Custom OpenAnalyst Plugin Setup
• API Tokens and Automations