Editorial policy 1.1 · Effective 22 October 2026
How listings are researched and reviewed
The directory applies one public inclusion test to vendor submissions, community contributions, and maintainer-authored entries. Passing that test establishes taxonomy fit; it does not establish product quality.
Evidence standard, after pass-fit
Material claims need a maintained first-party source
- Prefer the closest source. Product documentation, protocol specifications, release notes, source repositories, licence files, and official pricing pages take priority over summaries and directories.
- Match evidence to the claim. A homepage mention of “agents” does not support detailed claims about permissions, interfaces, deployment, pricing, or interoperability.
- Separate fact from positioning. Vendor terminology may be reported with attribution, but it is not converted into an independent performance or quality judgment.
- Use secondary sources only as context. Third-party coverage may help find a lead or explain a market, but it cannot replace first-party evidence for inclusion.
1 · Product fit, before evidence
Decide whether it is built for agents
Record pass-fit, fail-fit, or unclear-fit with the intended user, core job, and why the product is or is not built for agents. Use only the product description and operating model, plus canonical homepage positioning if necessary, not evidence arrays, documentation, MCP details, implementation, pricing, licence, or validation. Follow the product-fit gate: fail-fit stops with nonacceptance and unclear-fit holds for positioning clarification. Neither proceeds to evidence review, metadata enrichment, or listing commits.
2 · Verify
Check the specific evidence
Only pass-fit proceeds to full first-party evidence, schema, and contradiction review. A human-first app with REST, MCP, or SDK access cannot be rescued by integration depth or tool count. An AI agent serving humans is not, by itself, a tool built for agents. Agent-oriented infrastructure, protocols, and agent-builder tools may qualify when designed for agent operation, without exclusive agent use or agent-only origins.
3 · Classify
Choose one defensible class
Each accepted listing receives the most specific supported classification. Classification is not a rating, award, recommendation, or substitute for due diligence.
Experience and verification
Documentation review is not hands-on testing
Unless a listing explicitly describes a dated test and its conditions, it should be read as a review of public documentation, not evidence that the directory installed, purchased, benchmarked, or security-tested the tool. Superlatives and comparative claims require a disclosed method and supporting evidence; otherwise they are not editorial conclusions.
Review cadence
Review happens at submission and when material change is found
Every proposed listing is reviewed when it enters the directory. Existing entries are rechecked when a reader, vendor, contributor, or maintainer reports a material change or correction. The directory does not currently promise a fixed recurring re-review interval, so fast-changing facts such as price, availability, limits, and licence terms should be confirmed on the linked first-party source before a decision is made.
Conflicts, sponsorship, and affiliate links
Commercial relationships do not change the inclusion test
- Contributors should disclose employment, ownership, investment, or another material vendor relationship in the pull request.
- A maintainer relationship to a listed tool does not exempt the entry from evidence and classification requirements.
- The directory does not currently sell rankings or sponsored placement.
- Outbound listing links are not currently paid affiliate links. Any future compensated link or placement must be clearly labelled.
- Advertising or sponsorship, if introduced, will not guarantee acceptance and will not alter editorial classification.
Ordering
Position is not a score
Homepage listings are shuffled. Category and tool ordering can use an explicit maintenance value and otherwise falls back to readable label or name ordering. Placement does not represent quality, popularity, payment, market share, or editorial preference. Any future ranked recommendation will require a separate published methodology and will be labelled as a ranking.
Public record
Changes are proposed in public
Directory content is stored in a public GitHub repository. Proposed additions and material edits can be examined in pull requests, including the contributor identity and discussion available there. Public history is useful provenance, but submitter identity is not the same as editorial authorship or independent verification.
Corrections, appeals, and removals
Stronger evidence can change a decision
A reader or vendor may challenge a fact, classification, rejection, or removal with a specific first-party source. The maintainer may correct the wording, add a caveat, reclassify, temporarily unpublish, or remove an entry when evidence no longer supports it. A vendor request alone does not require publication or deletion of accurate public-interest information. The full process is documented in the corrections policy.
Content and data rights
No separate bulk-reuse licence has been declared
The repositories and live JSON/CSV exports are public for inspection, citation, and contribution, but their availability does not grant a separate open content or compiled-data licence for bulk republication. Link to the canonical page and attribute short quotations. Product names, logos, documentation, and other third-party materials remain subject to their owners' terms. Any future immutable research release will state explicit reuse terms next to that release.