Protocol Architecture - Context Protocol

Overview

Context is built on a Code Execution paradigm. Instead of rigid “tool calling” schemas, the Agent writes and executes TypeScript code to interact with the world. The architecture consists of four layers:

The Marketplace — Supply of tools from developers
The Agent — Demand from users executing queries
The Protocol — Settlement layer on Base
Context Injection — Portfolio data for personalized tools

The Marketplace (Supply)

Developers register Tools (the paid product) powered by standard Model Context Protocol servers. Just paste your endpoint URL and we auto-discover your skills via listTools().

Terminology

Term	Definition
Tool	The paid marketplace listing (what users see in the sidebar)
Skill	The execution function (can be called multiple times per tool payment)

How It Works

You build an MCP server exposing your data/APIs
You register it as an “MCP Tool” on Context with a price (e.g., $0.01/query)
When users query the AI, it discovers and calls your skills via callMcpSkill()
You get paid instantly in USDC on Base

The Data Broker Standard

Context is not a text-based chat platform — it is a Structured Data Marketplace. We treat your tool like a financial API, not a conversational bot.

Why `outputSchema` and `structuredContent` Matter

The MCP specification defines outputSchema and structuredContent as optional features for tools. Context requires them for all paid tools because structured data enables powerful marketplace features:

Feature	Without Schema	With Schema
AI Code Generation	Agent guesses response format	Agent writes precise parsing code
Type Safety	Runtime errors, broken parsing	Guaranteed structure
Dispute Resolution	Manual review required	Auto-adjudicated on-chain
Trust Signal	Unknown reliability	”Data Broker” verified

Why Context Requires These Fields

While optional in vanilla MCP, Context requires structured outputs because:

AI Agent Benefit: The agent uses your outputSchema to write accurate TypeScript code that parses your response correctly.
Payment Verification: Our smart contracts can verify that your returned JSON matches your promised schema.
Dispute Resolution: Schema mismatches can be auto-adjudicated on-chain without manual review.

Result: You are not just a “Prompt Engineer” — you are a Data Broker selling verifiable information on-chain.

The Agent (Demand)

When a user asks a complex question (e.g., “Is it profitable to arb Uniswap vs Aave?”), the Agent:

Discover

Finds relevant tools from the marketplace (or uses pre-selected ones)

Plan

Creates a solution using composability

Write Code

Generates code to invoke the necessary paid Tools via callMcpSkill()

Execute

Runs the code securely in our sandbox

Pay

Transfers fees instantly to developers via ContextRouter

Synthesize

Combines results into a coherent answer

Composability is the superpower of Context. Any frontier model can stitch together disparate tools into a coherent workflow, creating infinite new use cases from your single MCP server.

The Protocol (Settlement)

All value flows through ContextRouter.sol on Base.

Payment Distribution

Recipient	Share
Tool Developer	90%
Protocol Treasury	10%

When multiple tools are used, payments are batched into a single transaction.

Staking System

All tools (including free) require a minimum stake, enforced on-chain.

Tool Type	Minimum Stake
Free Tools	$10 USDC
Paid Tools	$10 USDC or 100× query price (whichever is higher)

Stake Properties

Fully refundable with a 7-day withdrawal delay
Creates accountability and enables slashing for fraud
On-chain enforcement via smart contracts

Security: Financial Protocol Architecture

We use Asymmetric Request Signing (RS256) to secure the marketplace. This is not just “auth” — it’s the foundation of a financial protocol.

Why This Matters

Approach	Result
Without Auth	A toy — anyone can `curl` your endpoint
With Shared Secrets	A security liability — secrets can leak
With Asymmetric Signing	Professional infrastructure (like Stripe/Visa)

How It Works

Platform signs requests with a private key (stored securely in environment)
Tool servers verify requests using the public key (distributed via SDK)
Short-lived tokens (2-minute expiration) prevent replay attacks

JWT Claims

Claim	Description
`iss`	`https://ctxprotocol.com` (issuer)
`aud`	Tool endpoint URL (audience)
`toolId`	Database ID of the tool being called
`iat`	Issue timestamp
`exp`	Expiration (2 minutes from issue)

For MCP Tool Developers

Secure your endpoint with a single line:

import { createContextMiddleware } from "@ctxprotocol/sdk";

// 1 line to secure your endpoint
app.use("/mcp", createContextMiddleware());

Context Injection (User Data)

For tools that need access to user-specific data (e.g., “Analyze my positions” or “Check my balances”), Context uses a Context Injection pattern.

Beyond Crypto: While we currently focus on on-chain portfolio data, this system is designed to inject any type of user context (identity, preferences, etc.) in the future without exposing sensitive credentials.

Step	Who	Action
1	User	Links external wallet/account in Settings
2	Context App	Checks tool’s `x-context-requirements` in `inputSchema`
3	Context App	Fetches data from protocol APIs (client-side)
4	Context App	Injects data as `portfolio` argument to tool
5	MCP Tool	Receives ready-to-analyze data, returns insights

Why This Matters

No Auth Required: Public data is fetched by the platform, so you don’t need to handle API keys or user login.
Security: MCP servers never see private keys or credentials.
Simplicity: Tool developers receive structured data directly in tool arguments.

Currently Supported

We are starting with high-value crypto data types:

Context Type	Description	Injected Data
`"hyperliquid"`	Hyperliquid perpetuals & spot	Positions, balances, account summary
`"polymarket"`	Polymarket prediction markets	Positions, orders, market data
`"wallet"`	Generic EVM wallet	Address, token balances for any chain

Declaring Context Requirements

If your tool needs user data, declare it using the _meta.contextRequirements field:

{
  name: "analyze_my_positions",
  
  // ✅ Use _meta for custom tool metadata (MCP spec)
  _meta: {
    contextRequirements: ["hyperliquid"]  // or "polymarket", "wallet"
  },
  
  inputSchema: {
    type: "object",
    properties: {
      portfolio: { type: "object" }
    },
    required: ["portfolio"]
  }
}

Why _meta? The MCP SDK strips non-standard fields from tools. The _meta field is part of the MCP specification for arbitrary tool metadata and is preserved through transport.

Tool Safety Limits

Each tool invocation runs inside a sandboxed code-execution environment.

MCP Tools Limits

Limit	Value
Max calls per turn	100
VM timeout	5000ms

Every callMcpSkill({ toolId, toolName, args }) increments an internal counter. Once executionCount >= 100, the platform throws an error for that turn.

Economic Model

Scenario	Behavior
Free tools ($0.00)	Can be used immediately without payment
Paid tools	Require user authorization via the sidebar
Multiple paid tools	Single batched transaction

Overview

Marketplace

Universal SDK

​Overview

​The Marketplace (Supply)

​Terminology

​How It Works

​The Data Broker Standard

​Why outputSchema and structuredContent Matter

​Why Context Requires These Fields

​The Agent (Demand)

​The Protocol (Settlement)

​Payment Distribution

​Staking System

​Stake Properties

​Security: Financial Protocol Architecture

​Why This Matters

​How It Works

​JWT Claims

​For MCP Tool Developers

​Context Injection (User Data)

​Why This Matters

​Currently Supported

​Declaring Context Requirements

​Tool Safety Limits

​MCP Tools Limits

​Economic Model

Overview

The Marketplace (Supply)

Terminology

How It Works

The Data Broker Standard

Why `outputSchema` and `structuredContent` Matter

Why Context Requires These Fields

The Agent (Demand)

The Protocol (Settlement)

Payment Distribution

Staking System

Stake Properties

Security: Financial Protocol Architecture

Why This Matters

How It Works

JWT Claims

For MCP Tool Developers

Context Injection (User Data)

Why This Matters

Currently Supported

Declaring Context Requirements

Tool Safety Limits

MCP Tools Limits

Economic Model