Projects worth a look
Not a star list but a selection with reasoning: harnesses, tool servers, measuring gear and curiosities - each with the paragraph explaining how it helps you build.
Model Context Protocol - reference servers
modelcontextprotocol/servers View on GitHub89,191 starsTypeScriptUpdated Aug 2026
The gathering point for MCP servers: reference implementations plus a long list of servers from the community.
Anyone who wants to hand an agent some tools runs into the same question early on: what does a tool have to look like so a model can use it safely? MCP answers that as a protocol, and this repository is where you read the answer in the original rather than in a summary.
The value is twofold. The reference servers are small enough to read end to end
- a filesystem server, a database server, a server for an external service. Afterwards you know how tool description, arguments and error returns fit together, and you can build your own servers without guessing. And the linked list of community servers is the fastest way to find out whether the integration you need already exists.
If you have read the building block on tool calling, this is the next step: the same idea, but as running code you can point a real agent at.
- tool-server
- mcp
- reference
83,073 starsTypeScriptUpdated Aug 2026
A complete, open agent harness - the rare case where you can read the loop from the outside instead of guessing at it.
A lot gets written about agent harnesses, but the interesting ones mostly run behind a closed door. OpenHands is the exception: an agent that writes code, runs commands and works in the browser - with its entire loop out in the open.
What pays off most is looking at the parts that blog posts leave out. How is the history trimmed once the context window fills up? What happens when a tool returns an error - abort, retry, replan? How is the execution environment fenced off so the agent cannot touch the whole system? Those are exactly the questions a homegrown harness fails on, and here the answers exist as code.
You do not have to adopt the agent for that. It is enough to use it as a textbook: one implementation you can hold your own decisions against.
- harness
- coding-agent
- open-source
55,510 starsPythonUpdated Aug 2026
A proxy that hides many providers behind a single OpenAI-compatible interface - and keeps count of what every call costs.
As soon as an agent lives longer than a weekend, the provider question shows up: a different model for the expensive steps, a local one for the cheap ones, a fallback for when an API stalls. Building that straight into the agent spreads provider knowledge across the whole codebase.
LiteLLM pulls that layer out. The agent keeps speaking the OpenAI chat format and the proxy translates it to whatever actually runs behind it. The translation itself is the less interesting part; what grows around it matters more: one place where keys live, where calls are logged, where cost and limits per user become visible. Exactly the things you skip in a first prototype and painfully miss in first real operation.
Useful as pure reading material too: the provider adapters show very concretely where the APIs differ - in tool calls, in streaming and in error messages.
- inference
- proxy
- provider
SWE-agent
SWE-agent/SWE-agent View on GitHub19,995 starsPythonUpdated Aug 2026
The research agent that solves real GitHub issues - and shows along the way how to measure agents in a comparable fashion at all.
Most agents look good in a demo. Whether they are actually any good only shows on a task nobody arranged for them - real, already closed GitHub issues, for instance, whose solution is known and whose tests you can run.
That is exactly the subject here. SWE-agent is an agent that works on such issues, and at the same time the showcase for a claim that is easy to underestimate when building agents: the tool surface is not a detail. A file editor that hands the model line numbers and context back after every change moves the success rate more than the tenth sentence in the system prompt. Anyone designing their own tools will find the most convincing argument here for shaping them from the model's point of view rather than the programmer's.
A second reason to look: the setup of the evaluation. One container per task, fixed starting conditions, a test run as the verdict - no model jury. That is the template for measuring your own agent instead of admiring it.
- eval
- benchmark
- research