When you connect an MCP server to your model, it adds a lot of context to every session, whether you need that MCP in the current session or not. When you add a few MCP servers, your available session context can drop by noticable amounts - and the LLM outputs also start to degrade because your context is full of irrelevant information.
Skills on the other hand are loaded only as-required. The initial context only gets awareness of the existence of available skills, so the initial context is hardly affected at all. You can have many skills and your initial available context is almost like on a virgin install.
What I did for Podio, InfoLobby, and Notion for example is something like this:
Create a skill for InfoLobby so you can interact with the API when needed. I have added my API key to my environment as 'INFOLOBBY_API_KEY'.
You can find the developer docs at: https://infolobby.com/api-docs.
Read all the docs and write me this skill, and call it 'infolobby-api'. I'd prefer if you used plain bash and curl to interact with the API.
That’s it. Your LLM can now use the API. The hardest part is adding your API key to your environment variables.
As you use the skill, you might find that there are a few issues. Not a problem. Use every bad session as learning, eg:
I noticed you struggled a bit with XXX.
Please update the skill with your learnings from this session.
At the end of the day, LLM’s aren’t complicated and training comes down to just a few markdown files. Instead of just using your LLM for your projects, use them for the LLM itself as well.
One last tip:
If you have multiple LLM’s, don’t duplicate your work. Put all skills and agent files in one place (that gets backed up regularly), and then just symlink them to .claude .codex .gemini etc. (also symlink AGENTS.md to CLAUDE.md for Claude).
In individual projects, you again have an AGENTS.md file (symlinked to CLAUDE.md) with project-specific notes.
That way ALL your LLM’s work the same way.