MCP Extensions

MCP Extensions

Overview

Partite Mesh integrates the Model Context Protocol (MCP) and adds two extensions to improve capabilities of tools exposed through MCP.

Server Initiated HTTP (Reverse Pull Extension)

A Partite-specific extension that inverts the normal request flow. Instead of exposing an inbound HTTP listener, a tool process initiates outbound connections to Partite and pulls queued work. The goal: make internal capabilities safely available to agents without adding inbound networking or complex authentication.

Motivation:

  • No inbound firewall holes or load balancer config
  • Easy local development (run a tool locally; connect to a cloud Mesh)
  • Horizontal scaling: multiple tool instances drain the same queue
  • Resilience: transient network issues do not drop in-flight calls—requests remain queued

Conceptual Flow:

  1. Tool connects using its MCP Connection credentials.
  2. Tool polls / long-polls for a pending task (queued invocation).
  3. Mesh delivers a task payload (tool name + structured arguments + artifact refs).
  4. Tool executes locally, streams optional progress, then posts completion (result or error).
  5. Mesh records trace events; result becomes a citeable source for grounding.

Characteristics:

  • Work queues persist until acknowledged.
  • Backoff/heartbeat semantics keep connections lightweight.
  • Stateless tool processes can scale elastically.

Integration Simplicity

The protocol is designed so existing applications can expose MCP tools with minimal surface changes:

  • Outbound-only: works in locked-down networks—no new ports, DNS, load balancer or TLS termination required.
  • Drop-in loop: install a client SDK (Go / Python / JS), start a lightweight worker that: connect → fetchTask() → execute → submitResult().
  • Reuse existing code: map incoming tool names directly to existing service functions or handlers; keep your current logging, metrics, config and DI setup.
  • Natural scaling: start more worker processes or containers; they cooperatively drain the same queue—no extra coordinator logic.
  • Safe retries: if a worker restarts mid-run the task stays queued until explicitly acknowledged; no lost calls.
  • Local development: point a local worker at a cloud connection to iterate without duplicating production networking.
  • Progressive adoption: expose one tool first; expand set over time without architectural reshaping.
  • Clear permission model: API key / connection scoping prevents accidental exposure of unrelated internal endpoints.
  • Language flexibility: any runtime that can make outbound HTTPS requests can participate; no server framework coupling.
  • Operational transparency: each task lifecycle (dispatch, start, finish, error) is traced—no custom instrumentation needed.

Result: adding MCP capabilities often amounts to a single background goroutine / thread or sidecar process, not a new microservice.

Artifact & Large Data Handling

Raw inclusion of massive result sets or documents in a prompt inflates token usage, degrades instruction focus, and slows responses. Mesh avoids this by turning large outputs into typed, addressable artifacts: a tool returns a lightweight reference (x-partite-ref) plus metadata; the underlying payload stays outside the context window while remaining interactable.

Goals:

  • Conserve tokens and reduce latency.
  • Preserve instruction clarity (avoid drowning critical guidance).
  • Enable stepwise analytical refinement.
  • Strengthen grounding (structured provenance of derived values).
  • Reuse intermediate computational products.

Mechanism:

  1. Tool emits artifact reference instead of raw content.
  2. Mesh supplies schema, size hints, and allowed operations to the agent.
  3. Agent invokes artifact-centric tools to narrow, transform, or summarize.
  4. Each operation yields a new immutable artifact (a traceable chain).
  5. Final textual outputs cite structured fields from produced artifacts.

Common operations (exposed as MCP tools bound to artifact types):

  • filter / query
  • project (select columns / fields)
  • sample (representative subset)
  • aggregate (group, stats, percentiles)
  • describe_schema / stats
  • summarize (narrative synthesis)
  • materialize_view (persist refinement)
  • export_subset (small citeable payload)

Database Example:

  1. select_initial_dataset → Artifact A (millions of rows, schema + ops).
  2. filter (service=‘api’, latency>500ms) → Artifact B.
  3. aggregate (endpoint latency stats) → Artifact C.
  4. sample (slow rows) → Artifact D.
  5. summarize (combine C metrics + D examples) → textual report citing C. Result: No full raw dataset enters the prompt; the agent “walks” the data space deliberately.

Benefits:

  • Token minimization: only metadata + targeted slices.
  • Faster iteration: small, purposeful context updates.
  • Grounded outputs: numeric/textual claims validated against artifact data.
  • Reusability: downstream agents can reuse artifacts without recomputation.
  • Safety: only declared, typed operations—avoids brittle freeform SQL.

Design Principles:

  • Typed references dictate safe operation surface.
  • Metadata is “just enough” (schema, counts, stats) for planning next steps.
  • Structured provenance enables audit trails and trace correlation.

Result: Large, complex data becomes incrementally explorable and verifiable without overwhelming the model, mirroring disciplined human analytic workflows while maintaining accuracy and traceability.

SDKs

To simplify usage of these capabilities, Partite.ai provides SDKs for common languages which integrate with the official MCP SDKS to add these capabilities seamlessly.

Message SchemasConfiguration As Code