MCP Evolution: Transforming Static Tools into Remote Skills with "Context Awareness"

In AI Agent engineering practice, Model Context Protocol (MCP) has become the standard bridge connecting large models with the external world. However, as application scenarios shift from "personal assistants" to "complex enterprise-level business," the traditional MCP interaction mode is beginning to reveal its "static" bottleneck.

Solon AI supports encapsulating MCP as Skills, achieving a leap from a "cold collection of APIs" to "intelligent skills with perception capabilities."

I. Three Major Pain Points of Static Tools

Traditional MCP interaction is similar to an "unclosable toolbox," where all tools flood in regardless of the scenario:

• Context Noise: Even a simple greeting injects hundreds or thousands of lines of tool schema definitions into the model, wasting tokens and interfering with the model's focus on inference.

• Security Risks: The model's visibility to tools is "full." It's difficult to dynamically hide sensitive operations (e.g., deleting an order) based on the currently logged-in user's role (e.g., regular user vs. administrator).

• Instruction Gap: The tool only provides "what can be done," but cannot tell the model "how to do it in the current context." The model lacks immediate instruction constraints specific to particular business scenarios.

II. Core Solutions: Perception, Mounting, and Dynamic Distribution

Solon AI addresses the above pain points by introducing a Skill (Solon AI Skills) lifecycle to wrap the MCP protocol, implementing the following mechanisms:

A. Intelligent Admission (isSupported):

Skills are only activated when the Prompt context (intent, tenant information, environment variables) meets the conditions.

B. Instruction Injection (getInstruction):

When a skill is mounted, a "behavioral guideline" (System Message) specific to the current context is automatically injected into the model.

C. Three-State Routing (getToolsName):

The server dynamically determines which tools to display to the model based on the Prompt attribute. Three routing modes are supported:

• Full Use: Displays all business tools when no filtering logic is defined.

• Precise Authorization: Only displays tools within the current user's permission scope.

• Complete Denial: Even if the skill is activated, security policies may block all tool calls at this time.

III. Practical Examples

1. Client-Side: Calling Like a Local Skill

Developers only need to focus on injecting business attributes; they don't need to worry about tool filtering logic. Everything is agreed upon and negotiated between the MCP Skill proxy and the remote server.

import org.noear.solon.ai.chat.ChatModel;
import org.noear.solon.ai.chat.prompt.Prompt;
import org.noear.solon.ai.mcp.McpChannel;
import org.noear.solon.ai.mcp.client.McpClientProvider;
import org.noear.solon.ai.mcp.client.McpSkillClient;

//Build the mcp client
McpClientProvider mcpClient = McpClientProvider.builder()
                .channel(McpChannel.STREAMABLE)
                .url("http://localhost:8081//skill/order")
                .build();

// Build prompt words with business attributes
Prompt prompt = Prompt.of("Help me cancel order A001")
                .attrPut("tenant_id", "solon_001")
                .attrPut("user_role", "ADMIN"); // Impersonating an administrator

// Inject skills and the model will only see tools with "administrator" permissions
chatModel.prompt(prompt)
         .options(o -> o.skillAdd(new McpSkillClient(mcpClient))) //Wrap the mcp client as Solon AI Skills
         .call();

2. Server-side: Implementing skills with "perception"

The server no longer blindly responds, but determines its behavior by parsing the Prompt.

import org.noear.solon.ai.annotation.ToolMapping;
import org.noear.solon.ai.chat.prompt.Prompt;
import org.noear.solon.ai.mcp.McpChannel;
import org.noear.solon.ai.mcp.server.McpSkillServer;
import org.noear.solon.ai.mcp.server.annotation.McpServerEndpoint;

import java.util.ArrayList;
import java.util.List;

@McpServerEndpoint(channel = McpChannel.STREAMABLE_STATELESS, mcpEndpoint = "/skill/order")
public class OrderSkillServer extends McpSkillServer {

    @Override
    public boolean isSupported(Prompt prompt) {
        // Perceived intent: Activated only when an "order" is involved and the tenant is compliant
        return prompt.getUserContent().contains("订单") 
               && prompt.attr("tenant_id") != null;
    }

    @Override
    public String getInstruction(Prompt prompt) {
        // Dynamic directives: Inject tenant-specific business rules
        return "你现在是租户[" + prompt.attr("tenant_id") + "]的订单助手。";
    }

    @Override
    public List<String> getToolsName(Prompt prompt) {
        // Privilege isolation: Dynamically issue tool names based on user roles
        List<String> tools = new ArrayList<>();
        tools.add("OrderQuery"); // 基础权限

        if ("ADMIN".equals(prompt.attr("user_role"))) {
            tools.add("OrderCancel"); // Visible only to administrators
        }
        return tools;
    }

    @ToolMapping(description = "Query order")
    public String OrderQuery(String id) { ... }

    @ToolMapping(description = "Cancel an order")
    public String OrderCancel(String id) { ... }
}

IV. Skills Architecture Reflection and Limitations Supplement

While evolving MCP into Skills brings significant engineering advantages, developers still need to clarify its technical boundaries:

• Non-standardized architectural enhancements:

LLM's underlying standard only includes Prompt and Tool-Call. Skills are not a native model standard, nor are they part of MCP's public protocol specification; rather, they are an architectural design pattern (a general pattern). They are typically implemented on the consumer side by AI development frameworks (such as Solon AI) to solve capability scheduling problems in complex business scenarios.

• Consumer-side driven customization:

The evolution from MCP to Skills is essentially "business-driven" or "domain-driven." When designing remote MCP Skills, deep customization must be performed with reference to the specific specifications of the consumer side (i.e., the Agent execution engine).

• Applicable Scenarios:

Tool: Suitable for simple functional plugins that are atomic, stateless, and fully public.

Skill: Suitable for complex business logic blocks requiring context awareness, multi-tenant isolation, and dynamic instruction constraints.

V. Summary of Benefits

After evolving MCP into Skills, your AI Agent architecture will gain:

• Extreme Context Purity:

The model only sees the tools it should see at that moment (on-demand loading via getToolsName, or access control).

• Natural Access Security:

True cross-process role-based access control (RBAC for Tools) is achieved through server-aware dynamic distribution.

• Loosely Coupled Business Evolution:

Business logic and rule changes are centralized on the server side; clients can obtain the latest capabilities "without" any code modifications.