Creating Values with MCP and Skill - OpenML's AI & Quantum Computing Blogs

MCP and Skill are Orthogonal#

To start with why, it helps to look at the distinct roles these two technologies play in the AI ecosystem. Agent Skills are designed as self-contained and client-side instruction packages, structured as folders containing SKILL.md, assets/, scripts/, and references/ that provide procedural knowledge and domain-specific playbooks directly to an AI agent. They are typically loaded locally or managed via client-side extensions and plugins using progressive disclosure, acting as the internal expertise or guiding framework of the agent.

In contrast, the Model Context Protocol is an open standard focused on extending an agent’s external capabilities by connecting AI applications to external data sources, applications, and services. MCP servers expose functionality through standardized primitives like tools, prompts, and resources, serving as the external connection layer for the agent.

NOTE
While MCP documentation does reference agent skills in the context of developer workflows, such as using specialized agent skills to help scaffold MCP servers and interactive applications, it maintains a clear separation between client-side skill bundles and server-side MCP protocols. Consequently, the MCP specification does not define any mechanism or protocol for an MCP server to integrate agent skill such as hosting or delivering an asset directory.

⚠️ Mixing MCP-as-a-Product and Skill-as-a-Product is a Critical Mistake#

Treating a skill marketplace and an MCP hub as the same product category creates a fundamental strategic mismatch. Skills are knowledge products meant to be distributed like open-source packages—decentralized, file-based, and lightweight. MCP servers are infrastructure products meant to be managed like enterprise services—centralized, secure, and runtime-bound.

TIP
Building a business around MCP means competing as infrastructure middleware, focusing on reliability, security, and integration depth.
Building around skills means focusing on domain-specific editorial quality, workflow automation design, and community-driven knowledge sharing.

Evaluating Skills and MCP (Model Context Protocol) as distinct software products reveals two fundamentally different paradigms for extending AI agents. While both aim to make agents more capable, they operate in completely separate layers of the AI technology stack, commanding entirely different business models, go-to-market strategies, and operational requirements.

Skill as a Product sells proprietary domain expertise, workflow methodologies, coding standards, and step-by-step reasoning logic. It is essentially static, deterministic intellectual property packaged into portable natural-language structures and local scripts.

MCP as a Product delivers live runtime connectivity, secure data transport, and API interoperability. It is a dynamic infrastructure, protocol translation, and stateful execution middleware

On Distribution#

The Model Context Protocol was created specifically to solve an integration and interoperability problem. As a result, its architecture centers on a single, unified specification. Because executing external tools carries operational and security risks, MCP required formal standardization from day one to ensure clients could safely manage and talk to server processes across different platforms.
Agent skills follow a pattern similar to early open-source package management or Markdown specifications. The protocol deliberately leaves distribution unconstrained. Because a skill consists entirely of static context files, host applications and agents can load them through local file paths, Git repositories, archive downloads, or custom registries without requiring a specialized network transport protocol. For example:
- Most agent harnesses and clients look for skills in both project-local paths and a global user directory. We can place our skill once in a global machine-level configuration directory (such as ~/.config/agent/skills/my-skill or our client’s designated global path)
- Maintain a central repository like mlflow/skills
  
  mlflow
  /
  skills
  Waiting for api.github.com...
  00K
  0K
  0K
  Waiting...

On Security#

Risk Profile of MCP: MCP servers actively touch the real world. They process multi-tenant user authentication (OAuth 2.0, PKCE), execute database writes, manage API tokens, and mutate external state. This places MCP firmly in the realm of enterprise governance, requiring rigorous audit logging, rate-limiting, and zero-trust security postures.
Risk Profile of Skills: Because skills are primarily text instructions evaluated locally by the agent using progressive disclosure, they carry minimal infrastructure risk. Security concerns are generally limited to prompt injection or behavioral steering, which are handled at the client level.

MCP-as-a-Product#

Systems such as Gemini Extensions and ChatGPT Plugins allows OpenAI and Gemini to connect to external apps and services to retrieve real-time information and perform actions, allowing them to interact directly with Google Workspace (Docs, Drive, Gmail), Google Maps, Google Flights, Google Hotels, and YouTube.

The general technology and industry trends behind systems like Gemini Extensions and ChatGPT Plugins fall under a few distinct terms, depending on whether we are describing the foundational mechanism, the software architecture, or the broader ecosystem.

Function Calling and Tool Use: At the foundational level, this capability is widely referred to as Function Calling or Tool Use. Instead of relying purely on pre-trained weights, the AI is trained to recognize when it needs external help and generates structured data to execute standard Python functions or external APIs.
Agentic Tooling and ReAct Architecture: When function calling is paired with autonomous decision-making, it is known as Agentic Tooling. This is heavily driven by architectures like ReAct (Reasoning and Acting). In this framework, the LLM acts as the brain generating internal reasoning traces, while the integrated tools serve as the external action space.
Extensibility Ecosystems and MCP: At the platform level, these plugin networks are known as Extensibility Ecosystems. To prevent developers from having to write custom integrations for every AI model, the industry is standardizing around technologies like the Model Context Protocol (MCP), an open-source standard that provides a universal way for AI agents to connect securely to external data sources, local systems, and tools.

Extensibility Ecosystems as Technology#

The architectural term for ChatGPT Plugins is Tool Registries or MCP Hubs. At a technical level, these ecosystems serve as catalogs where an AI model dynamically queries and invokes external capabilities.

Tool Registries: The underlying technical mechanism where third-party APIs, functions, or execution scopes are registered so an agent can pick the right “tool” for a given user intent.
MCP Servers / Hubs: With the widespread adoption of open connection standards like Anthropic’s Model Context Protocol (MCP), these ecosystems are often referred to as MCP Hubs or MCP Registries. They allow an app or agent to dynamically discover external tool definitions and execute them on demand.

Extensibility Ecosystems as Platform#

As a backend infrastructure that bridges LLMs to the real world via standardized protocols. extensibility system solves the hard problems of enterprise software integration - security, discovery, authorization, and multi-tenancy.

How Standard Protocols like MCP Govern Extensibility Ecosystems?#

Standardized open protocols like the Model Context Protocol (MCP) solve a fundamental architectural challenge in agentic AI: how an AI agent safely discovers, understands, and executes third-party tools at runtime without hardcoding integrations or rebuilding prompt templates for every external capability.

Before open protocols, every AI app built a proprietary plugin architecture. MCP decouples the host client (the AI app or IDE) from the external tools, acting as a universal language for tool discovery and execution.

The Dynamic Discovery Workflow#

When an agentic system connects to an MCP-based server, dynamic tool discovery operates through a standard client-server request-response lifecycle:

Discovery & Handshake (tools/list): Upon startup or user selection, the AI client sends a standardized RPC request (such as tools/list) to the connected MCP server or gateway. The server returns a structured array of all available capabilities, complete with exact parameter requirements and JSON schemas.
In-Context Prompt Synthesis: The AI agent converts these JSON schemas into system-level instruction definitions. Because the protocol uses standardized formats (like JSON Schema for arguments), the model knows precisely what inputs are required (e.g., string format, required parameters, default values) without developer intervention.
Intent Matching & Planning: When a user submits a prompt (e.g., “Export this table to Google Sheets”), the model analyzes the dynamic tool definitions currently loaded in its context window. If a registered tool matches the intent, the model generates a structured JSON payload containing the arguments.
Invocation & Output Binding (tools/call): The client receives the model’s structural tool call and sends a tools/call RPC message to the target MCP server with the generated arguments. The MCP server executes the underlying code/API call and returns a standardized result payload back to the agent context.

Architectural Layer	Role in Dynamic Tool Discovery
JSON-RPC Transport Layer	Standardized messaging format over standard channels (stdio, SSE, HTTP/WebSockets), allowing local or remote servers to plug into any agent without native code compilation.
Semantic Self-Description	Tools provide human-readable descriptions alongside rigid input schemas. The LLM uses these descriptions to decide when and why to invoke a specific tool.
Stateless Scope Boundaries	Servers expose atomic primitives - Tools (executable actions), Resources (readable data streams), and Prompts (reusable templates) - allowing servers to enforce fine-grained user permissions.

MCP Market is NOT “MCP Server/Hub”
Although matching syntatically, MCP Market and MCP Server/Hub represent two different layers of the ecosystem:

MCP Market is a Public Community Directory/Registry. It serves as a human-facing web catalog (like npm, PyPI, or an app store listing) where developers publish, browse, and discover open-source MCP server implementations, installation guides, and documentation. It does not sit inside our active application request lifecycle or execute code for our AI agent.

MCP Server/Hub is an Active Runtime Gateway / Backend Server. It is the live infrastructure endpoint (such as our backend Node.js server or a hosted container) that directly accepts streamable HTTP/SSE requests, executes the underlying tool logic, handles token authorization, and communicates back and forth with the LLM at runtime via JSON-RPC protocol messages.

Fundamental Components of Enterprise-Grade MCP Server or Hub#

From a first-principles engineering perspective, an enterprise-grade MCP Server or Hub breaks down into 5 essential foundational components:

1 - Unified Transport & Protocol Engine (Data Plane)#

This component handles low-level network connectivity, protocol parsing, and response framing:

JSON-RPC Dispatcher: Deserializes incoming tools/list and tools/call RPC payloads and routes them to the correct execution handler.
Streamable Network Adapters: Exposes stateful, bidirectional streaming transports—such as Server-Sent Events (SSE), WebSockets, or Streamable HTTP - over TLS to support continuous agent execution loops.

2 - Semantic Discovery & Context Trimming Engine#

Exposing hundreds of tool schemas at once exhausts the LLM’s context window and skyrockets token costs.

Vector Tool Index: Stores embeddings of tool descriptions and parameter schemas.
Dynamic Search & Filtering: When an agent queries the hub, this engine performs semantic similarity matching over the prompt to retrieve and expose only the top $N$ relevant tool schemas during the tools/list handshake.

The embeddings are generated from tool metadata documents during an automated indexing pipeline, and the vector search is performed against a centralized Vector Database (Registry).

3 - Protocol Adapter & Translation Layer#

When building an AI MCP server with hundreds of tools, we face a major issue: our AI agent speaks only MCP (Model Context Protocol / JSON-RPC), but the real-world software services we want to trigger (like Spotify, Salesforce, or Google Calendar) do not speak MCP—they speak standard REST, GraphQL, or gRPC.

Instead of writing custom backend code (like spotify.ts or salesforce.ts) to bridge every single service by hand, the Protocol Adapter automates this process.

4 - Identity, Authorization & Token Exchange (Control Plane)#

AI agents must execute actions using the specific end-user’s permissions rather than over-privileged system credentials.

Identity Context Propagation: Intercepts incoming tools/call requests and extracts the user’s bearer token (OAuth2/OIDC).
Token Vault Integration: Injects user-specific OAuth refresh/access tokens into downstream requests to ensure zero-trust, role-based access control (RBAC)

5 - Governance, Safety & Telemetry.#

In an autonomous environment, this layer prevents malicious agent behavior and system abuse.

Prompt Injection & Tool Poisoning Guardrails: Inspects incoming inputs and returning execution results for adversarial payload patterns before returning them to the LLM.
Rate Limits & Circuit Breakers: Enforces strict execution budget caps, execution timeouts, and rate limits to stop runaway recursive agent loops.
Audit Logging: Centralizes telemetry, tracking token usage, latency, user context, and exact input/output payloads.

General Extensibility Ecosystem Architecture#

A standard MCP Server/Hub backed system is ChatGPT Plugins (or ChatGPT Apps):

Implementation#

In the case of an already functioning webservice, it is an optimal architectural approach to build the MCP extensibility engine as an isolated, standalone subsystem before integrating it into the existing webservice system. Decoupling the MCP server/hub from webservice’s domain layer allows ys to verify protocol compliance independently, protects our existing graph pipeline during development, and sets up a clean path to swap out existing components if needed.

What is a Domain Layer?
In software architecture (specifically Domain-Driven Design), the Domain Layer is the core heart of an application. It contains the business logic, rules, and models that dictate what the application does, completely independent of external concerns like databases, frameworks, or user interfaces.

Specifically, the architectural rationales for this separatin of concern are:

Separation of Protocol vs. Domain: The Model Context Protocol (MCP) governs transport, JSON-RPC routing, dynamic discovery, authorization, and execution sandboxing. Neo4j graph traversal and Cypher querying are application domain concerns. Keeping them decoupled prevents protocol glue code from polluting your knowledge graph logic.