Oluwatobi Oyewole studied petroleum engineering before moving into software. He began with enterprise systems, then moved into product engineering. Through Andela, he worked with international teams on products for organisations including Science Corporation and Kinship, part of Mars Petcare.
His more recent work centres on a practical question about AI assistants. Once an assistant has access to a tool, how does it learn the instructions needed to use it well?
That question drew him into the Model Context Protocol (MCP) community, where he tested ways of making reusable instructions, known as skills, available to AI applications.
His experiments led to three accepted contributions to the MCP Skills extension repository and initial work incorporated into the official MCP TypeScript software development kit (SDK).
In this interview with ROYAL IBEH, he discusses what those experiments revealed, what he learned from other contributors, and why he wants more Nigerian developers to get involved.
For someone outside software engineering, what does MCP do, and where do skills fit in?
MCP is an open standard for connecting AI applications to tools and data. Imagine an assistant connected to a company’s inventory system or customer-support platform. Developers can use MCP to give it access to approved information and supported actions through a common interface.
The question I became interested in was what happens after that connection. An assistant might have access to a tool without knowing the workflow it belongs to. A skill provides reusable instructions that the assistant can read when it needs guidance.
One of my experiments used a dice-rolling tool and a skill that explained tabletop dice notation. I asked the assistant what an expression like 5d10dh1 meant. The tool could execute the notation, but it wasn’t designed to explain it. I observed the client retrieve the skill’s main instruction file, then a reference document about the notation. That gave me a practical example of how tools and skills could work together.
What made you want to work on this problem?
There were discussions about whether developers needed MCP if they already had skills, and whether skills were necessary if MCP already existed. I could see a use for both. MCP could provide access to a capability, and a skill could explain how to use it for a particular task.
I found the MCP Skills working group and started joining the discussions. One question was how the proposed extension would behave in development environments that already supported MCP. I volunteered to investigate Visual Studio Code. It gave me a specific problem to work on and a way to contribute something useful.
What did that first investigation involve?
I built an experimental implementation in my own fork of VS Code and tested it against a live Hugging Face MCP server. It discovered eight skills and made their descriptions available to the model.
That was encouraging, although there was a limit to what I could conclude. I hadn’t fully verified whether the model would choose to load those skills on its own, so I documented that alongside the results.
The findings were accepted into the MCP Skills extension repository. As the specification changed, I went back to test the newer discovery methods and how the client retrieved and verified skill files. The VS Code implementation remained in my experimental fork; it wasn’t merged into Microsoft’s upstream project.
What surprised you when you tested it?
How quickly a small implementation choice could create extra work for a server. In the first experiment, a naive approach to discovery generated about 20 reads of the skills index during one chat turn. That raised an immediate question about caching: how could the client avoid asking for the same information repeatedly?
Later, I saw the other side of that problem. In one experiment, the client reused a skills listing for about 27 hours across several connections. If a server changes its skill files during that time, the client could still be relying on an old listing. Caching saves requests, but you also have to decide when to refresh what you’ve stored.
I also observed a session in which the assistant preferred calling an available tool to reading the skill intended to guide its use. Having the instructions available didn’t guarantee the model would consult them.
Those findings formed part of three accepted contributions covering early discovery, client behaviour and metadata interoperability. The third explored how a metadata key using the io.modelcontextprotocol/ namespace could be preserved and recognised in skill files. Each experiment helped identify details that needed more attention.
How did the experiments lead to work on the TypeScript SDK?
At the time, the official SDK didn’t have dedicated APIs for the Skills extension. Developers could build the functionality with existing MCP capabilities, but they had to handle some of the Skills-specific work themselves. After experimenting in VS Code, I wanted to help make that easier.
I proposed the integration, then submitted an initial implementation. My contribution covered TypeScript types and validation schemas, client operations for listing and retrieving skills, server request handlers, and capability negotiation, which lets a client and server establish what each supports. I also submitted a conformance-testing fixture to check behaviour against the specification.
Konstantin Konstantinov led the final implementation, which was merged on 20 October 2026. It built on my earlier work, retained my commits and explicitly credited my contributions. It also added substantial functionality beyond my submission, including loading skills from the filesystem and verifying retrieved resources.
I’m pleased that my work became part of that implementation. The public review history shows how different contributions came together. It’s too early to say how widely developers will use it.
What did working with the maintainers teach you?
The reviews showed me how much there is to consider when a prototype becomes part of a maintained SDK. Other contributors expanded the work to address requirements I hadn’t fully covered. Following those changes helped me understand their decisions.
One issue I investigated involved a response that appeared to contain the right information but still failed validation. Tracing it through the SDK showed that a field was being removed during decoding, before the application’s schema saw it. The schema had to account for that existing behaviour. It was a useful reminder to understand the surrounding system before deciding what to change. I also learned to be patient with reviews. Maintainers have other responsibilities, and a substantial contribution takes time to assess. Ola, one of the Skills extension maintainers, later recognised my consistency and follow-through. That meant a lot because it came from someone who had reviewed the work. I would volunteered to investigate a problem, and I would stayed with it.
Before this, you worked on products for international teams. Which project stands out?
The consolidation of Kinship’s UK and US websites. The company had separate web domains for the two markets, and we needed to bring them under a unified domain structure while keeping the functionality each market required.
I was given technical leadership responsibility for the project. It meant understanding the frontend, the Gatsby framework underneath it, routing, backend integrations and deployment. I also had to coordinate with other engineers and keep the technical decisions moving towards the deadline.
We completed the consolidation, and the experience changed how I understood technical leadership. Solving a difficult programming problem was one part of the job. I also had to help the team deliver the whole project.
How did that product work change the way you make engineering decisions?
It made me pay closer attention to what happens after a feature is built. In our experimentation work, for example, we wanted to understand how different sign-up flows affected customers. I helped introduce a more structured approach to A/B testing, including mutually exclusive experiments to reduce interference between overlapping tests.
That gave the team a way to compare user behaviour and conversion data before deciding which experience to use. We could investigate a product question rather than rely on assumptions about what customers would prefer.
Working on products for UK and US customers also exposed me to consent management. I worked with OneTrust and analytics platforms to understand how a person’s consent preferences affected tracking and data collection. Those requirements had to be considered as part of how the application behaved.
You demonstrated MCP at a Cursor developer meetup at the University of Lagos. What did you want people to take away?
I wanted them to see how they could build something themselves. I’d submitted a talk proposal and was selected, so I used the session to build an MCP server and connect it to ChatGPT. Then I showed how the assistant could interact with the functionality the server exposed.
I would already been experimenting with similar technology professionally, and a live demonstration felt like a useful way to share what I’d learned. You can explain the idea with slides, but watching the connection work makes the steps easier to understand. My aim was to make MCP feel more accessible to the developers in the room.
You have also spoken to secondary-school students about technology careers. Why is that important to you?
Students use phones, websites and apps all the time, but they may not have thought much about the people who build and maintain them. I wanted to introduce them to that work and the careers around it.
Software development is one option. There is also product management, design, cybersecurity and data, among other areas. My own path began in petroleum engineering, so I know a career can change direction. I wanted the students to understand that they have room to explore.
What would you say to a Nigerian developer who wants to contribute to open source but isn’t sure where to start?
Start with a project you use or care about. Read the documentation, look through the issues and spend some time understanding the code. Reproducing a bug or testing a feature can be a useful first contribution. So can improving documentation when you’ve found something unclear.
You will also need to learn how the community works. Understand the direction of the project, explain what you are proposing and respond to feedback. A pull request may take time to review, so patience matters.
Open source gives engineers a way to work together across countries without having to relocate. In my case, volunteering to investigate a specific problem gave me a way in. As I understood more, I found other places where I could help.
What are you interested in working on next?
I am still interested in how AI applications discover and use external capabilities. With the Skills extension, I want to learn what happens as developers put it to use. Where do clients struggle? Which parts are difficult to implement?
The experiments have made me more curious about what sits behind the tools I use. I used to install libraries and focus mostly on what I could build with them. Now I am also looking at the decisions behind them and the problems their maintainers are trying to solve. That’s where I’d like to keep contributing.
Royal Ibeh is a senior journalist with years of experience reporting on Nigeria’s technology and health sectors. She currently covers the Technology and Health beats for BusinessDay newspaper, where she writes in-depth stories on digital innovation, telecom infrastructure, healthcare systems, and public health policies.
