This started almost accidentally. I opened the agents experience while trying to optimise and review some code. A few iterations later, I had built my first working MCP server.

The moment Copilot felt like a starting point

GitHub Copilot exposes a growing world of agents, pre-built MCP servers and tools. I had seen what other teams and companies were doing with AI, but much of it still felt distant. Inside Copilot, it suddenly felt approachable: this was somewhere I could begin, experiment and build something useful for my own workflow.

My need was simple to explain. An application contained information I needed, and I wanted to ask for it directly in Copilot Chat. Because the application offered authorised APIs, I started exploring how I could make that workflow simpler and more conversational.

Looking past the user interface

At first, I only knew the application through its user interface. Then I realised that, like many modern applications, it also offered authorised APIs for integrations. That changed the question from “Can I access this?” to “How can I interact with it more naturally?”

APIs were not new to me. I had seen colleagues build useful Python applications around them, and I already understood JavaScript from front-end development. But MCP presented the same building blocks in a new way. Instead of manually sending requests in a tool such as Postman, an AI agent could understand a set of clearly described tools, choose the right one and use the response in context.

What an MCP tool changes

Imagine an application where a user can read data, create a post, add or edit a comment, tag someone, review an item or delete an outdated entry. Each action usually maps to an API operation.

An MCP server can make those operations available as understandable tools. The agent does not need a vague instruction to “use the API.” It gets a defined tool with a purpose, expected inputs and a predictable result. The conversational layer becomes easier, but the permissions and rules of the underlying application still matter.

Building it with GitHub Copilot

I built the server with Node.js and TypeScript. I knew enough JavaScript to follow what was happening, but I did not begin with a complete architecture or a carefully written specification. I worked in Copilot's agent mode and described what I needed: connect to this authorised endpoint, create a tool for this action, handle the response and make it available in chat.

Copilot generated the structure and code, while I supplied the context, tested the behaviour and decided what the next version needed. Voice input also made it easier to explain longer changes naturally instead of turning every thought into a perfect prompt first.

The important part was not accepting code blindly. Even when AI writes most of the implementation, I still need to understand what data it touches, how authentication is handled and whether the tool respects the application's access controls.

Version one was only the beginning

The first version worked, and then real use exposed what it could not do. I could add a comment, but I could not edit or delete one. That gap became the next prompt, the next tool and the next version.

This pattern kept repeating. I would use the server, notice a missing action, describe it to Copilot, test the update and improve the tool. The MCP server did not arrive fully formed. It grew around actual needs, which made each addition easier to justify and verify.

The lesson I am taking forward

If an application does not already have an MCP server but does provide APIs you are authorised to use, you may not need to wait for someone else to build the integration. A focused MCP server can begin with one safe, valuable tool and expand from there.

A practical starting sequence is:

  1. Choose one genuine workflow problem, not an entire application.
  2. Confirm the API, authentication method and your permission to use both.
  3. Start with a read-only tool when possible.
  4. Describe the tool clearly: its purpose, inputs and expected output.
  5. Test failures and permission boundaries, not only the happy path.
  6. Add write actions only when the need and safeguards are clear.
  7. Let real usage decide what version two should contain.

My first MCP server began with curiosity rather than a grand plan. GitHub Copilot lowered the technical barrier, but the useful part came from understanding the workflow and improving it one missing capability at a time. That is what made the experiment feel real: it stopped being a demo and became something I could actually use.