/// EDITORIAL POLICY
Updated June 7, 2026
HOW CLAWSITES
REVIEWS LISTINGS_
ClawSites is a discovery directory for OpenClaw, Hermes Agent, AI agent tools, MCP resources, browser agents, and adjacent automation projects. This policy explains how listings are reviewed, how guide pages are updated, and how corrections should be handled when product facts change.
SHORT ANSWER
ClawSites reviews listings as a practical directory, not as a certification body. A listing should have a reachable official source, a clear category, an understandable workflow description, and enough context for a reader to decide what to verify next. Product owners remain the authority for current pricing, setup instructions, security details, compatibility, and supported integrations.
Purpose of this policy
Readers use ClawSites to discover tools before they install software, connect accounts, send messages, automate browsers, expose files, or build workflows around an agent. The directory should make that research safer by keeping discovery signals, limitations, and verification steps visible.
Agent tools can change quickly. A project may add a hosted plan, remove a free tier, switch model providers, change supported clients, or expand the permissions it requests. Because of that, ClawSites treats listings as maintained discovery notes. The directory helps readers find candidates and compare them, but it should not imply that every product detail has been tested continuously or that a tool is approved for production use.
The editorial standard is simple: a listing should help a reader ask better questions. What job does the tool support? What official source should be checked? What access does it need? What evidence can the user review after a run? Which category contains comparable options? If a listing does not answer those questions directly, the surrounding page should provide enough context for the reader to continue carefully.
This policy also applies to guide pages. Guides should explain terms, compare tradeoffs, and link to relevant directory pages without overstating what a tool can do. When an official source is the only reliable place for a changing detail, ClawSites should point readers there instead of presenting unstable information as permanent.
Review workflow
A review is a directory-quality check. It focuses on relevance, clarity, source reachability, category fit, and reader safety. It is not a legal, financial, security, or compliance audit of the listed product.
| Step | Owner | Review check |
|---|---|---|
| Submission intake | Directory reviewer | Confirm that the submitted URL loads, the project is relevant to OpenClaw or adjacent AI agent workflows, and the description is understandable without marketing filler. |
| Category placement | Directory reviewer | Assign the listing to the closest useful category so readers can compare it with tools that solve a similar job. |
| Source check | Directory reviewer | Use the official source as the authority for current product facts such as setup path, supported integrations, pricing, permissions, and ownership. |
| Safety context | Directory reviewer | Add or maintain guidance that reminds readers to verify permissions, account access, output review, logs, and rollback before adopting a tool. |
| Update review | ClawSites | Refresh stale listings, remove broken destinations when needed, and update guide pages when categories, examples, or official sources materially change. |
Listing signals and limits
ClawSites uses lightweight signals to organize a fast-moving market. Those signals are useful, but they have limits. A reader should treat them as research aids and then confirm the product facts at the official source before connecting sensitive systems.
Working destination
Readers need to reach the tool owner or official documentation before they can verify anything else.
A working link does not prove reliability, security, or product fit.
Clear category
Categories help readers compare similar options instead of mixing unrelated agents, MCP servers, browser tools, and marketplaces.
A category is a discovery aid, not an endorsement.
Specific description
A useful listing says what the tool helps a person do, which workflow it supports, and what kind of user should inspect it.
Descriptions can become stale when the product changes.
Visible source path
Readers should know where to confirm docs, pricing, install instructions, changelogs, and security notes.
ClawSites does not replace the owner source.
Community interaction
Votes and listing activity can help readers notice tools that deserve a closer look.
Votes are not proof of safety, authority, or procurement readiness.
Updates, corrections, and removals
Corrections matter because outdated directory information can send readers toward the wrong tool, the wrong category, or the wrong source. ClawSites should update listings when a broken link is found, when a product changes its positioning, when a category no longer fits, or when a description no longer matches the official source.
If a tool owner sees an issue, the useful correction path is specific: identify the listing, explain the factual problem, provide the official source that confirms the change, and suggest the smallest accurate update. The strongest corrections improve clarity without turning a listing into a sales page.
Removal is appropriate when a destination is unavailable for a sustained period, the page no longer represents an OpenClaw or AI agent workflow, the listing duplicates another active entry, or the listing would mislead readers even after a concise correction.
Correct factual errors when a listing points to the wrong tool, uses an outdated description, has a broken destination, or places a project in a misleading category.
Prefer precise, verifiable wording over broad claims. If a product owner says a tool supports a feature, the listing should still help readers find the source that confirms the current implementation.
Remove or revise a listing when the destination no longer works, the project is no longer relevant to the directory, or the page creates a confusing path for readers.
Avoid copying setup commands, pricing, compatibility promises, or security claims unless they are stable enough to summarize. When those details can change quickly, link readers to the owner source.
Freshness and update triggers
A directory page can become less useful even when the link still works. A tool may move from a local project to a hosted product, change its onboarding path, introduce a new permission model, add a paid plan, remove a public demo, or narrow the audience it serves. Those changes can affect how a reader should compare the tool, so ClawSites treats freshness as part of directory quality.
Updates are most important when a change affects user decisions. A spelling fix is useful, but a category change, a new official source, a pricing change, a broken destination, a major security note, or a new setup requirement is more important because it changes the next verification step. When a guide explains a category such as browser agents, MCP servers, open-source agents, or business adoption, the examples should continue to match the way readers actually evaluate that category.
ClawSites does not need to rewrite every page for every small product update. The goal is to keep the directory accurate enough that readers are not misrouted. If a product fact is likely to change often, the page should summarize the stable concept and send readers to the official source for the changing detail. If a product fact is central to comparison, the listing should be updated when a reliable source shows that the old description is no longer accurate.
What ClawSites does not claim
ClawSites does not guarantee rankings, uptime, security, legal compliance, vendor support, procurement approval, or workflow success for any listed product. The directory also does not claim that a tool is safe for private data, payment actions, customer communication, repository writes, browser sessions, or production automation simply because it appears in the directory.
A listing can be useful even when the reader still needs a separate review. For example, a browser agent may be interesting because it can operate a web interface, but a team still needs to test session isolation, replay evidence, credential handling, and failure behavior. An MCP server may be useful because it exposes a tool to an agent, but the team still needs to review scopes, authentication, logs, and deployment model. An open-source agent may be inspectable, but the team still needs to verify license fit, maintenance activity, setup burden, and local permissions.
The safest way to use ClawSites is to move from broad discovery to a narrow test. Pick a single workflow, read the official source, grant the smallest useful access, run a realistic trial, keep a record of what happened, and decide whether the tool deserves a larger role. That process is slower than trusting a directory label, but it produces better decisions.
Related resources
Directory Methodology
How ClawSites categorizes listings and turns directory data into useful comparison context.
Read guideOpenClaw Security
A practical review path for permissions, browser access, credentials, logs, approvals, and rollback.
Read guideEcosystem Report
Live directory counts, category depth, pricing signals, tag trends, and adoption notes.
Read guideFor readers and tool owners
Readers should use ClawSites to build a shortlist, not to skip evaluation. The directory is most useful when it points you toward the right category, the right official source, and the right questions to ask before adoption. If a workflow touches private data, production systems, money, customer messages, or irreversible actions, add a human review point and keep logs that explain what happened.
Tool owners should keep listings factual. A good submission explains the current product, the workflow it supports, the category it belongs in, and the source a reader can use to confirm details. If the product changes materially, submit a correction with the official source and the exact detail that should change.
ClawSites will continue improving this policy as the directory grows. The goal is not to make a static rulebook. The goal is to keep discovery useful, honest, and clear enough that developers, founders, operators, and researchers can compare agent tools without confusing directory presence with product approval.