can we expose source code implimentation of a mcp tool to client instead to asking LLM to call the tool.

[awais-kaleem-blocksdev]

Pre-submission Checklist

• I have checked that this question would not be more appropriate as an issue in a specific repository
• I have searched existing discussions and documentation for answers

Question Category

• Protocol Specification
• SDK Usage
• Server Implementation
• General Implementation
• Documentation
• Other

Your Question

for example i am using stripe mcp server with vs code.
i ask copilot to create a stripe user.
it calls the tool provided by stripe MCP to create a user and return me stripe_user_id.

but i do not want the LLM to call that tool.
i want my LLM to get the source code of that MCP tool and make an api on backend to to create stripe user.

in this way i have chance to get a perfect standerized implimentation of backend api provided by MCP server.

i know that there is resoarce opthon in MCP.

do we have a way to attach that function in resoarce,
or is there any config flag in tool to expose source code also.

[awais-kaleem-blocksdev]

it would b nice option to enable for every MCP server's related to dev SDKs like stripe etc

[awais-kaleem-blocksdev]

@mcp.tool
def multiply(a: float, b: float) -> float:
    return a * b

@mcp.resource("tools://multiply/source")
def multiply_source():
    return """
    @mcp.tool
    def multiply(a: float, b: float) -> float:
        return a * b
    """

i tried this solution. it works
but there should be more efficient solution instead of re writing source code again as string

if possible kindle let me know otherwise it is requested to add this feature

[AwaisBinKaleem]

modelcontextprotocol/modelcontextprotocol#1390

[isheng-eqi]

Great question — this touches on a fundamental architectural difference between MCP and the newer Agent Skills protocol.

Short answer

MCP does not natively expose tool source code to clients, and this is by design. Tools in MCP are intentionally black boxes: the host only sees name, description, and inputSchema. The implementation is opaque.

Why MCP chose black-box tools

MCP tools are API contracts, not code snippets. The design philosophy is:

• Security boundary — the tool implementation may contain secrets, internal URLs, or proprietary logic the server owner does not want to leak
• Abstraction — the LLM should not need to know how a tool works, only what it does. This is the same reason REST APIs do not ship their backend source code alongside their OpenAPI spec
• Language/stack independence — the client should not care whether the server is written in Python, TypeScript, or Go

The workaround you already found

Exposing source code as an MCP resource (your tools://multiply/source pattern) is clever and does work. But as you noted, it requires duplicating the source as a string — brittle and not scalable.

A cleaner variant: have the resource dynamically read the tool's source file at runtime using inspect.getsource() (Python) or fs.readFileSync() (Node), so you are not maintaining the code twice.

The bigger picture: MCP vs Agent Skills

This question actually reveals a genuine architectural gap in MCP. There is a newer protocol — Agent Skills (Anthropic, see modelcontextprotocol/experimental-ext-skills) — that takes the opposite approach:

	MCP Tools	Agent Skills
What the LLM sees	description + inputSchema	Full implementation (script + instructions)
Execution	Server-side only	Host can execute locally
Philosophy	"Here is what I can do, trust me"	"Here is how I do it, decide for yourself"

For your Stripe use case specifically: an Agent Skill would ship the actual API integration code that the LLM reads, understands, and can adapt into the user's backend. MCP tools, by contrast, expect the LLM to call them as remote procedures.

Recommendation

If your goal is "LLM reads the source code and generates a backend endpoint," you have two paths:

1. Resource-based pattern (MCP): expose tool source via resources with dynamic file reading. Works today, but is a workaround.
2. Agent Skills (newer protocol): designed for exactly this use case — implementation exposure to the host. Track modelcontextprotocol/experimental-ext-skills for progress.

Neither is "wrong" — they serve different trust models. MCP assumes the server is the authority; Skills assume the host should have full visibility.