agent-protocol

Agent Protocol

The agent designs tool schemas for MCP, Google A2A, and OpenAI Function Calling protocols. It implements transport selection, capability discovery, authentication flows (OAuth 2.1, API keys), structured error handling, rate limiting, and protocol bridges for heterogeneous agent ecosystems.

Core Capabilities

1. Protocol Selection and Comparison

• MCP (Model Context Protocol): Anthropic's standard for tool/resource/prompt serving
• Google A2A (Agent-to-Agent): Agent card discovery, task lifecycle, streaming
• OpenAI Function Calling: JSON Schema tool definitions, parallel calls, strict mode
• LangChain/LangGraph Tools: Python-native tool wrappers with callback integration
• Custom Protocols: WebSocket, gRPC, and event-driven agent messaging

2. Tool Schema Design

• JSON Schema validation for inputs and outputs
• Semantic naming conventions that improve agent tool selection
• Description engineering for maximum LLM comprehension
• Required vs optional parameter design
• Enum constraints and default value strategies

3. Transport and Discovery

• stdio, SSE, and WebSocket transport for MCP
• HTTP+JSON-RPC for A2A task management
• Agent card and capability advertisement
• Health checking and graceful degradation
• Protocol version negotiation

4. Security and Authentication

• OAuth 2.1 flows for MCP remote servers
• API key rotation and scoping
• Request signing and verification
• Rate limiting per agent identity
• Audit logging for all inter-agent calls

When to Use

• Designing tool interfaces for LLM-powered agents
• Building MCP servers that expose APIs to Claude, Cursor, or other clients
• Implementing agent-to-agent communication in multi-agent systems
• Bridging between different agent protocols (MCP to A2A, etc.)
• Standardizing tool calling patterns across a team or organization
• Debugging agent tool selection failures

Protocol Comparison Matrix

| Feature | MCP | A2A | OpenAI Functions | LangChain Tools | |---------|-----|-----|-----------------|-----------------| | Transport | stdio/SSE/WebSocket | HTTP+JSON-RPC | HTTP REST | In-process | | Discovery | Server capabilities | Agent cards | API spec | Registry | | Streaming | SSE notifications | SSE streaming | Streaming deltas | Callbacks | | Auth | OAuth 2.1 | Agent auth | API key | N/A | | State | Resources + context | Task lifecycle | Conversation | Memory | | Multi-turn | Sampling | Task updates | Thread context | Chain state | | File handling | Resource URIs | Artifact parts | File search | Document loaders | | Best for | Tool serving | Agent networks | Single-model tools | Python pipelines |

Decision Framework

What are you building?
│
├─ Tools for a single LLM client (Claude, Cursor, Copilot)
│  └─ Use MCP — it's the native protocol for tool serving
│
├─ Agent-to-agent communication across organizations
│  └─ Use A2A — designed for cross-boundary agent discovery and delegation
│
├─ Tools for OpenAI models specifically
│  └─ Use OpenAI Function Calling — tightest integration
│
├─ Python pipeline with multiple chained tools
│  └─ Use LangChain Tools — simplest for in-process orchestration
│
└─ Heterogeneous agent ecosystem (multiple protocols)
   └─ Use Protocol Bridge pattern — translate between protocols at boundaries

MCP Tool Schema Design

Anatomy of a Well-Designed Tool

{
  "name": "search_documents",
  "description": "Search the knowledge base for documents matching a query. Returns ranked results with titles, snippets, and relevance scores. Use this when the user asks a question that requires looking up information from stored documents.",
  "inputSchema": {
    "type": "object",
    "properties": {
      "query": {
        "type": "string",
        "description": "Natural language search query. Be specific — 'Q4 2025 revenue projections' works better than 'revenue'."
      },
      "limit": {
        "type": "integer",
        "description": "Maximum number of results to return.",
        "default": 10,
        "minimum": 1,
        "maximum": 50
      },
      "filters": {
        "type": "object",
        "description": "Optional filters to narrow results.",
        "properties": {
          "date_after": {
            "type": "string",
            "format": "date",
            "description": "Only return documents created after this date (YYYY-MM-DD)."
          },
          "document_type": {
            "type": "string",
            "enum": ["report", "memo", "presentation", "spreadsheet"],
            "description": "Filter by document type."
          }
        }
      }
    },
    "required": ["query"]
  }
}

Tool Naming Rules

GOOD tool names (verb_noun, specific):
  search_documents      — clear action + target
  create_github_issue   — includes the service for disambiguation
  get_user_profile      — standard CRUD verb
  analyze_pr_diff       — describes the analysis action
  send_slack_message    — action + channel type

BAD tool names (vague, ambiguous, or too generic):
  search                — search what?
  do_thing              — meaningless
  handler               — not a verb_noun
  processData           — camelCase breaks conventions
  get_stuff             — too vague for LLM selection

Description Engineering

The description is the single most important field for agent tool selection. An LLM reads the description to decide whether to call this tool.

EFFECTIVE description pattern:
"[What it does]. [What it returns]. [When to use it]."

Example:
"Search the knowledge base for documents matching a query. Returns ranked
results with titles, snippets, and relevance scores. Use this when the
user asks a question that requires looking up stored documents."

INEFFECTIVE descriptions:
"Searches documents."           — too short, no usage guidance
"This tool is used for..."      — wastes tokens on filler
"A powerful search engine..."   — marketing copy, not instructions

MCP Server Implementation (TypeScript)

Minimal Server with Tool and Resource

import { McpServer } from "@modelcontextprotocol/sdk/server/mcp.js";
import { StdioServerTransport } from "@modelcontextprotocol/sdk/server/stdio.js";
import { z } from "zod";

const server = new McpServer({
  name: "project-tools",
  version: "1.0.0",
  capabilities: {
    tools: {},
    resources: {},
  },
});

// Tool: search codebase
server.tool(
  "search_codebase",
  "Search the project codebase for files matching a pattern. Returns file paths and line numbers with matching content. Use when looking for implementations, definitions, or usage of specific code patterns.",
  {
    pattern: z.string().describe("Regex or glob pattern to search for"),
    file_type: z.enum(["ts", "py", "go", "rs", "all"]).default("all")
      .describe("Filter by file extension"),
    max_results: z.number().int().min(1).max(100).default(20)
      .describe("Maximum results to return"),
  },
  async ({ pattern, file_type, max_results }) => {
    // Implementation: run ripgrep or similar
    const results = await searchFiles(pattern, file_type, max_results);
    return {
      content: [{
        type: "text",
        text: JSON.stringify(results, null, 2),
      }],
    };
  }
);

// Resource: project structure
server.resource(
  "project://structure",
  "project://structure",
  async (uri) => ({
    contents: [{
      uri: uri.href,
      mimeType: "application/json",
      text: JSON.stringify(await getProjectStructure()),
    }],
  })
);

// Start server
const transport = new StdioServerTransport();
await server.connect(transport);

MCP Server with Authentication (SSE Transport)

import { McpServer } from "@modelcontextprotocol/sdk/server/mcp.js";
import { SSEServerTransport } from "@modelcontextprotocol/sdk/server/sse.js";
import express from "express";

const app = express();

// Authentication middleware
function authenticateAgent(req, res, next) {
  const token = req.he