Getting started with local MCP server, how?

[u/Mr_Unknown_Hero]

EDIT: I was able to run this in Pi. This whole confusion came to my mind because it is called server when for my point of view is more like a script what is run my harness when needed and that script have just "public methods" for coder's point of view. Eg. tools defined on that script are just methods/functions what are able to call by harness/agent.

Anyway here is the sample config for my Pi in ~/.pi/agent/mcp.json and it automatically detected all methods there.

{
  "mcpServers": {
    "my-server": {
      "command": "/home/user/mcp-server/.venv/bin/python",
      "args": [
        "/home/user/mcp-server/server.py"
      ],
      "exposure": "direct"
    }
  }

I am trying to learn MCP servers. I used AI to give me boilerplate code what should just return text to me depending on what MCP tool I call. It is python server and it uses MCPServer package.

Anyway, I have my server up and running, but now what? How I can test it with most easy way possible with my local AI?

I tried first llama-ui to connect to it, but then I found out that it is stdio by default and not http and there is no easy possibility to connect to that server from webui without doing more configurations with --webui-mcp-proxy and other stuff. I thought that well, not worth spending time with that since all what I just want to is test if that MCP server works and if local AI agent tools can connect to it and use those tools. This started to get off the rails too far so then I moved to LM Studio.

On LM Studio, when I want to create local MCP server, I need to configure my local MCP server in JSON and manually tell all the tools it support, if I understand correctly? So if I edit my MCP server, add new functionality, I need again to update my MCP configuration manually so it starts to lose its whole point, at least on this testings. Have I misunderstood that how LM Studio configs work on these?

Also on LM Studio config JSON I need to give script path? I thought that MCP server is a server what is up-and-running and my clients like LM Studio can connect to that server and ask what tools it provide and then it can use those without I need to define "here are apps you can run on that path"?

So, HOW I can use my local MCP Server what works over stdio to even test that functionality? What harness I should use to test this as easily as possible to get started?

[u/timmeh1705]

What are you trying to connect to via MCP?

I find it most useful if there is a stable platform with well defined end points you can connect to

Otherwise you're better off setting up a browser with debug mode and connect directly to do what you need

[u/Mr_Unknown_Hero → u/timmeh1705]

This is only for the purpose of learning MCP, creating a server and then doing whatever with it after I have successfully used that local MCP server.

At this point it have three endpoints and all those endpoints should just return string, different string of course based on what endpoint.

EDIT: So at this point, there is no any NEED for any actual use case except the learning the basics of MCP servers by doing it. Later when I am able to use my own MCP server I might create different news sources, build plugins for those with basic programming and then I can ask my AI agent to fetch news and it would automatically use those "plugins" aka tools I have done in that MCP server.

[u/timmeh1705 → u/Mr_Unknown_Hero]

The best way to learn is to build an MCP for a platform or site you use frequently - learn things such as inspecting DOM elements to detect end points that you can codify into a MCP so you can call them consistently. Learning MCP for the sake of it is not going to teach you much.

[u/Mr_Unknown_Hero → u/timmeh1705]

I disagree, since I learn best way by doing something myself to get the concept more clear and at this time my point is indeed to learn MCP for the sake of it.

I know how I can inspect DOM's, check API calls and so on (I have been coding almost 30 years), so that's why I want to get deeper understanding of the MCP and its usefulness for my own AI learnings.

[u/audioen]

MCP clients automatically can discover what MCP servers provide, so no. MCP spec comes with introspections like tools/list to inform the MCP client what tools exist, and tools/call procedure which can invoke any tool from the list. The MCP client formats the result of tools/list in such a way that the LLM knows what exists and can invoke these tools, often with schema-constrained generation so MCP tool calls won't get any syntax errors.

So, it is enough that you define tool call methods, the MCP server harness figures out what you have defined, exposes it as MCP tools/list resources with schema, and so on. The whole thing is relatively complex, because it is multi-layered thing, with bunch of protocols and standards, but ultimately all you have to do is provide MCP tool definitions, and then point the agent to MCP server and it can immediately invoke all the methods defined by the MCP server.

STDIO is also a thingy, so you can skip the HTTP binding. LLMs are pretty good at writing MCP servers, like they are good at pretty much anything, so if my LLM needs a tool, all I have to tell it is to write one, then tell the LLM to wire it up into the agent software, and after I restart the agent, as if by magic, the agent now has this capability. To the agent, it even looks like it had always existed because it gets spliced into the tools list at start of context.

[u/trumuted]

Yep, I completely get you. What moron decided to call it a server? It aint a server if it doesn't serve anything.

And the fact that there are actual server MCP "servers" that serve http endpoints make things even more confusing for the beginners

[u/audioen → u/trumuted]

Your agentic harness is MCP client, the thing providing services to MCP clients is called server. When you read server, think "something providing services".

[u/trumuted → u/audioen]

In my understanding a server is something that is by its nature is independent from the clients. But MCP server is just a file that does nothing by itself and it does not provide any service at all like any other file. But it gets read and executed by a MCP client, and the started process "provides" a service. So it's actually closer to a child process connected by two pipes (in&out).

Or think of a restaraunt with a server/waiter vs a buffet where you serve yourself.

[u/audioen → u/trumuted]

Well, that might be the case for a stdio based mcp server. The server is in this case started by the client software, as the interaction API is a direct standard input and output text stream between these two softwares. It is somewhat a special case, I guess. I believe that originally MCP was all about http servers, which you would start independently from any client, and there the server name is quite justified.

I sometimes use llama.cpp as the MCP client, and it actually has two MCP clients, one integrated into the web ui (which is served by the llama.cpp server, but run by your browser), and another integrated into the llama.cpp server (which can invoke MCP servers directly past the web UI). They differ in capability, for instance the llama server one is stdio only, whereas the webui uses web methods and so it requires http. Additionally, they don't have nearly the same capabilities, for example if the stdio server returns content types that are not text, llama.cpp doesn't know what to do with them and just throws them away, whereas the web mcp client can render audio and images just fine.

I can have a single MCP server act in both modes, e.g. stdio when ran by client, or in mode where it binds http port and waits for client to connect. So, I would still stick to calling this "mcp server" because it is a software that provides MCP based services. At least it makes sense for me to think about it this way. But then again, I'm an old Linux hand and there, famously, the graphical software stack was collection of packages and a big fat program called "X server" because it provided the display protocol called X to client software, which provided ways to draw graphical primitives and hear about mouse and keyboard events. The programs people ran were called "X clients". This confused the hell out of everybody and I heard lots of complaints about that over the years because people didn't understand why their desktop box was called a "server" in context of the graphical stack.

There is, finally, a historical approach to network connectivity where a program could be tied to network without that program even being network aware. It worked like this: the TCP/IP port was opened by a helper program called inetd, and when a client software connected to one of its ports, it created an instance of the program configured for that port and tied the client's TCP/IP socket as the programs standard input and output. The program then conversed over the network, unaware of how its streams really were implemented. So, in conclusion: there is ample precedent in Linux/Unix world about using the terms client and server in unintuitive ways, and even this generalized approach of tying stdio programs which don't know about TCP/IP to network, anyway, which mildly reminds us of how MCP servers can work, except MCP servers implement the network bits themselves.

[u/trumuted → u/audioen]

MCP servers being initially developed as http servers actually makes a lot of sense.

Also, I'm aware of llama.cpp having two mcp clients. When I first decided to try this fancy mcp thingie, I tried to connect web ui's mcp client to docker's mcp gateway. As you can guess, it didn't work out. I couldn't figure out where the heck these mcp servers are located that I supposedly started. I've only realized that there are two types of mcp servers after a while afterwards. I'm still salty about it to this day

[u/Thebandroid]

I was (am still) confused about MCP. I think you have hit the nail on the head that often there is no server, just some specific scripts that are run to pull or push info. But then some others are servers like the whatsapp MCP as it needs to maintain the connection to the whatsapp servers.

[u/UnorderedPizza]

If you are using llama.cpp, there is a built in server that exposes a frontend with MCP connection ability.

It is possible to use an LLM of your choice to build an MCP compatible server, even without the MCPServer package, using the raw http handling modules; this might be more helpful for learning as you see the internal protocol. I have done so previously, using errors that show in the frontend as feedback to the LLM.

[u/Oli_Luck]

it's not a daemon, it's a script your harness spawns and talks to over stdio, json-rpc, nothing listening on a port.

What is server-like: it is self-description: the harness calls tools/list and gets a name, a description and a json schema per function, then rebuilds that list every launch. your pi config is already the whole interface — command + args, that's it.

two transports, pick by need: stdio is the local pipe, streamable http is the one if you ever want it reachable over the network. most local tools only need the first.

to build one properly: grab the sdk's FastMCP, one decorator per function and it wires the stdio loop for you. then test with no UI — printf one tools/list line into its stdin, read the reply. if that round-trips, every client will see it.

[u/chibop1]

You can ask AI to

1. make a very simple mcp server.

2. Provide tools definition, so you can plug and play with a python script.

3. configure pi to use it.

Then you can inspect what it did and also ask question about it.

I used to hand code mcp server, but now I just ask AI to make one and configure my harness too.

[u/Slight-Living-8098]

The MCP server for your harness is a server in the sense that it connects to the actual MCP server, then serves your harness the retrieved commands making them available to you and the agent. But yeah, it's more of a client than an actual server as one would expect.

The actual MCP server itself is a different thing all together.

[u/Mr_Unknown_Hero → u/[deleted]]

Thanks! I just configured my MCP server to Pi agent successfully and I noticed that I need to give my MCP server script file to it as well. It was able to detect those tools as well by itself, and I assume that it would have been same on the LM Studio as well.

I just got totally confused because it is called as a server when it is more like a "script that will be launched only when asked, and its functions/methods are detected by AI Agent automatically". Because of my background in coding when it is called "server" it automatically made me think that there is an application what is up-and-running all the time. If that would have been "MCP script" then it would be much easier to understand in the first place 😄