top of page
jetagent2-transparent.gif
Jetlink Logo (3).png

From Custom to Standard: How Jetlink’s Cross-Agent Protocol Speaks MCP

  • Jetlink
  • 4 days ago
  • 3 min read
ree


Introduction

In the rapidly evolving world of agentic AI, interoperability is no longer a nice-to-have—it’s the key to scaling. Enterprises don’t want siloed assistants; they want a connected ecosystem where agents can seamlessly exchange information, trigger actions, and integrate with external systems.

At Jetlink, we’ve invested heavily in typed interfaces and a cross-agent handoff protocol that make our multi-agent environments robust and efficient. But as the broader ecosystem rallies behind the Model Context Protocol (MCP), a natural question emerges:

How does Jetlink’s custom protocol map to MCP—and why should our customers care?


Why MCP Matters Now

Think of MCP as the USB-C of AI systems. It’s an open standard, backed by players like OpenAI and Google, that defines how agents talk to external tools and data sources. Instead of bespoke connectors for every SaaS platform, MCP promises a uniform handshake: predictable authentication, typed schemas, and consistent logging.

For enterprises, this means:

  • Faster integrations: “Plug-and-play” connections with the growing MCP server ecosystem.

  • Governance by design: Built-in scopes, policies, and observability.

  • Future-proofing: As MCP adoption accelerates, compatibility becomes a competitive advantage.


Mapping Jetlink Concepts to MCP

The good news: Jetlink’s architecture aligns naturally with MCP. Here’s a quick translation table:

Jetlink Concept

MCP Equivalent

Agent Action / Tool

MCP Tool

Typed Interfaces

MCP Input/Output Schemas

Cross-Agent Handoff

MCP Server Discovery

Orchestrator & Guardrails

MCP Authorization Hooks

This conceptual overlap means we can “speak MCP” without abandoning the strengths of Jetlink’s protocol.



Three Integration Patterns


1. Proxy (Quick Bridge)

Jetlink agents continue speaking our internal protocol, but a lightweight proxy converts requests into MCP calls.

  • ✅ Speed: Ideal for proofs of concept.

  • ❌ Trade-off: Two layers of configuration, long-term maintenance overhead.


2. Dual-Stack (Phased Transition)

Agents can call both Jetlink and MCP tools. You start by routing 10% of traffic to MCP, validate results, and scale up.

  • ✅ Risk control: Shadow testing and A/B comparisons.

  • ❌ Complexity: Temporarily maintaining both stacks.


3. Native (Full Adoption)

Jetlink actions are defined directly as MCP tool invocations.

  • ✅ Cleanest design: Unified observability and governance.

  • ❌ Investment: Requires upfront schema and policy harmonization.


Example: Order Status Check

Let’s make it concrete. A customer asks, “Where is my order?”

  1. The Jetlink orchestrator triggers the order_status action with orderId.

      2. A proxy translates the payload into an MCP tool call: { "order_id": "12345", "locale": "en-US" }


      3. The MCP server queries the Order Management System and returns a typed result.

      4. Jetlink applies role-based filters (masking sensitive fields) and delivers a user-friendly response.

If the MCP server times out, Jetlink gracefully falls back: “We’re checking your order status right now. It may take a moment. Would you like us to notify you once it’s ready?”


Governance and Observability

Integrating MCP is not just about connectivity—it’s about control. Here are non-negotiables:

  • Token Scopes: Never grant more authority than necessary.

  • Audit Logs: Every tool call should have a correlation ID tying it to a user request.

  • Human-in-the-Loop: For high-risk actions (refunds, cancellations), add approval workflows.

  • Error Recovery: Define “undo” strategies where possible—rollback actions build trust.


Lessons Learned

Through early pilots, we’ve observed:

  • Latency is manageable with Streamable HTTP (vs. SSE), especially in voice-driven use cases.

  • Schemas are gold: Typed I/O reduces runtime errors and debugging overhead.

  • Customers trust transparency: When agents explain what action they’re taking, adoption rises.


Conclusion

MCP is not here to replace Jetlink’s cross-agent protocol. It’s here to complement it. By mapping our internal strengths—typed interfaces, orchestrated handoffs—onto MCP’s standard, we unlock:

  • Faster external integrations.

  • Stronger governance and security.

  • Future-proof compatibility with the growing MCP ecosystem.

Our recommendation? Start small. Use a proxy for quick wins, move to dual-stack for validation, and evolve into native MCP for strategic use cases.

Jetlink’s vision has always been about connecting intelligent agents to real-world outcomes. With MCP, that vision becomes interoperable at scale.





 
 
 
bottom of page