How to get a list of all tools from the current server?

[jaywork2020]

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

I'm following the example from the MCP C# SDK:
https://github.com/modelcontextprotocol/csharp-sdk/blob/f135355bf985297d03ce6084dd131a31f231672f/src/ModelContextProtocol.AspNetCore/README.md

In that example, the server is explicitly configured with:

builder.WebHost.ConfigureKestrel(options =>
{
    options.ListenLocalhost(3001);
});

However, in my setup, I'm not using this ConfigureKestrel configuration at all.

Is this a valid approach, or do I need to explicitly enable Kestrel to host the MCP server?

Also, I want to connect to this server from another part of the same application, essentially having the app act as both an MCP server and an MCP client (connecting to itself locally).
What’s the best way to do this without explicitly specifying a port?

[PederHP]

If it's the same application, then an in-memory transport is an option. You should be able to find some of the test code setups doing that and I think someone is working on making that transport an explicitly available option alongside the other transport.

But why not simply call the tools directly if you're hosting the server in the same application?

[jaywork2020]

Thanks for your quick response @PederHP.

I have an internal application that allows users to create a chat through a UI. This app uses the Microsoft.Extensions.AI library to communicate with the models. Users can also select specific functions they want the model to be allowed to call.

Now, I’m working on integrating the app with the MCP client and server. Using the MCP client, I can let users provide settings to connect to a remote MCP server. However, I also want to give them the option to use a local MCP server so that my instance can access any McpServerTool.

Since my application calls the model directly using IChatClient, I initially thought that including the McpServerTools (e.g., AITool) in the request would be enough for the model to invoke functions hosted locally. But I’m not sure this will work without having an IMcpClient to properly route and invoke those functions.

So, I’m considering creating an instance of IMcpClient and using an in-memory setup to allow the model to connect and invoke tools from the local MCP server. But not entirely sure is this is the right approach and how to create an in-memory option.

[PederHP]

Just managed to delete my follow-up answer by accident. I'll try again.

Having some tools provided by in-process code and some by MCP servers is a relatively common pattern. I've used it myself and I've seen others use it. In fact most MCP client hosts have non-MCP tools as well.

So I'd just make the AIFunctions the aggregate of the connected MCP server tools and your own AIFunctions. You don't really gain anything from making your application an MCP server, and you get exactly the same functionality by just mixing AIFunctions and McpClientTools.

If what you want is to proxy all the remote servers through your in-process MCP server, that's not really possible. It would need to also be a client and forward the calls, and then you're back where you started, and have added a layer of indirection that doesn't do anything. But I am not sure if that's what you meant.

[jaywork2020]

Let me try to clarify and give a more complete picture.

My application is modular and decoupled. Each module has the ability to configure Microsoft.Extensions.AI.ChatOptions. Specifically, different modules can implement handlers that dynamically add tools to ChatOptions.Tools when a request is made. These handlers configure the tools based on settings provided to the model via the UI.

Now, why use an MCP server?

The goal is to allow external projects to connect to my MCP server and use the tools it exposes. At the same time, I also want my local application—the same one hosting the MCP server—to be able to use those same tools internally. So essentially, I want to expose tools for external clients while also making them available for internal use, all through the same mechanism.

In one of the handlers that configures ChatOptions.Tools, I want to include the MCP tools exposed by my server. That’s why I’m considering creating an in-memory MCP client within that handler. This way, I can fetch and use the tools internally without incurring the latency of a remote call. Meanwhile, other modules can contribute their own tools—non-MCP ones—based on user selection, and those get added to ChatOptions.Tools as well.

Hopefully, this gives a clearer picture of the architecture and what I’m trying to achieve.

[PederHP]

Yes, if you have an MCP server that is also an MCP client, then it makes sense to use an in-memory transport. And if you want external projects to connect - then you might as well reuse the logic for internal tool serving.

Personally, if I happen to have tools in my applications or services that I want to use both internally and externally, then I would separate that logic into a distinct MCP server and avoid the overhead and complexity of being both server and client. But I can see there are cases where it's not possible to do that. If so, then your approach makes perfect sense, and I would say - in that case implement an InMemoryTransport. You'll have to implement it yourself, via ITransport and IClientTransport - but it's not too tricky. It's really just wiring things up.

I'll be the devil's advocate though - and say make sure you have good reason to not simply extract your tools into a separate MCP server. In my experience it's better for scalability and robustness if services do not have multiple responsibilities like being both MCP server and local application service.

I would not recommend trying to convert the primitives (ie the server to client tool type conversion). It's either implement an in-memory transport or separate the concerns.

[jaywork2020]

@PederHP I'm still getting familiar with the project, so I'm not entirely sure if I have enough context to correctly implement an in-memory client. After implementing ITransport and IClientTransport, should I still use McpClientFactory.CreateAsync() to create the McpClient?

If so, what should my McpServerConfig look like in an in-memory setup? Do I need to register it using AddMcpServer() as shown in [this extension method](

csharp-sdk/src/ModelContextProtocol/Configuration/McpServerServiceCollectionExtensions.cs

Lines 17 to 27 in 5d7c2a1

	public static IMcpServerBuilder AddMcpServer(this IServiceCollection services, Action<McpServerOptions>? configureOptions = null)
	{
	services.AddOptions();
	services.AddTransient<IConfigureOptions<McpServerOptions>, McpServerOptionsSetup>();
	if (configureOptions is not null)
	{
	services.Configure(configureOptions);
	}
	return new DefaultMcpServerBuilder(services);
	}

), or is there additional configuration required when working outside of a full DI setup?

[MikeAlhayek]

Hi @PederHP – I'm working on something very similar to what @jaywork2020 did. Specifically, I'm implementing an Orchard Core module that provides a feature allowing users to provide an MCP server from within the tenant, so that it can be accessed by external MCP clients.

In addition to that, I also want to give users the ability to connect to their own MCP server from within the app itself (i.e., the app would act as a client as well). You can see the current state of my work in this PR:
🔗 CrestApps/CrestApps.OrchardCore#78

My library lets users define an "AI Profile" via AI—a way to configure everything related to a model, including deployment settings, system messages, parameters, MCP connection settings, etc. One option I’m trying to support is allowing a model to connect to the MCP server that's hosted within the currently running Orchard Core tenant.

Here’s where I enable the MCP server inside the Orchard Core tenant:
📄 Startup file

And this is the spot where I attempt to create an in-memory MCP client to connect to the local server and register its tools into the current chat request:
📄 Client setup

Do you have any suggestions for improving this setup? Especially when it comes to correctly creating an in-memory transport for the MCP client to talk to the local server? I'd really appreciate your thoughts.

[MikeAlhayek]

@PederHP I've updated my PR to separate the MCP client and server implementations. The MCP client portion has been merged, while the server implementation is still pending. This split should help reduce noise and keep each PR focused on a single, well-defined feature.

After the refactor, here's the code where I'm attempting to create a client that connects to a local (in-memory) server:
https://github.com/CrestApps/CrestApps.OrchardCore/pull/81/files#diff-8f0b83e02ee61881ec30fbf96b21aa250c0639c4dd6e914d0196b7adeeeec167R27-R33

Do you have any suggestions for improving this setup? Especially when it comes to correctly creating an in-memory transport for the MCP client to talk to the local server? I'd really appreciate your thoughts.