How we curate AgentStack.

How a component gets in

Every component in the directory has been read about, looked at, and decided on by Edy Appenzeller. Four signals drive the decision:

• Documentation. Does the project tell you how to run it? Is the README more than a one-liner? Are there real install instructions, not just "clone and figure it out"?
• Maintenance. Is anyone still answering issues and shipping releases? A quiet repo is not always a dead repo, but it costs time to verify, and the entry says so when I cannot.
• Capability. Does it solve a real problem an MCP client can actually use? "Look at me, I am an MCP server" is not enough - the function has to do something useful when the agent calls it.
• Trust. Is the publisher real? Are the permissions proportionate to what the component does? Will the agent surprise the user?

If a component clears all four, it gets in. If any signal is weak, the entry says so on the page. The full entry for each component lives at /mcp/<slug> and is the substance - the directory card is the headline.

What we do on each review

For every listing I write a long-form entry covering: what the component is, who maintains it, when to use it, when not to use it, and what permissions it actually asks for. I check the public repository for release cadence, issue responsiveness, and any open security disclosures. I cross-reference the source directory for prior editorial context. Then I date the entry, sign it as the reviewer, and link back to the original source for transparency.

This is editorial work, not a hands-on test. I do not install every component in a sandbox before publishing. Where I have, the entry says so. Where I have not, the entry says that too.

What we will not claim

Three things this directory is not:

• It is not a security review. The "Permissions and security" section on each entry is what the publisher documents, not what we have audited. For sensitive workloads, read the publisher's security documentation directly.
• It is not a "we use this in production" seal. Some entries I have run for my own work; some I have not. The entry is honest about which is which.
• It is not the most complete directory. The source directory reports more components; we curate a smaller, more careful selection. Empty categories are not a bug - they are an honest "we have not curated enough here yet" signal.

How a listing gets removed

A component leaves the directory for one of four reasons:

• The project is abandoned (no releases, no responses, broken installs).
• The project changes in a way that breaks the trust signal (license flip, undisclosed telemetry, hostile maintainer takeover).
• The component gets superseded by a clearly better alternative in the same slot.
• The component no longer maps to a real MCP use case the directory serves.

Removals land in the changelog with the reason. If a removed component later recovers, it can come back through the same review process any new entry goes through.

Where the source data comes from

AgentStack is built on top of data from the original AgentStack directory, which is the canonical source for the project metadata. We take that metadata, run it through the editorial process above, and write a long-form entry for every component we keep. The original source remains the authoritative reference; this site is a curated selection with editorial context that the source does not provide.

If a source listing and our entry disagree, the source wins on technical facts (versions, dependencies, current maintainer). The editorial voice - the "is this worth your time" call - is ours, not the source's.

Editorial independence

Featured placement is decided by the editor, not paid for. We do not run sponsored reviews. We do not sell placements. If a project wants to flag a correction, the contact page routes straight to the editor.