/// ABOUT US
THE OPEN
CLAW DIRECTORY_
ClawSites is an unofficial directory of websites, tools, and SaaS platforms connected to the OpenClaw and AI agent ecosystem. We help developers, operators, creators, and researchers discover tools, compare workflows, and verify useful resources before they connect accounts or build around them.
What is ClawSites?
ClawSites (also known as the OpenClaw Directory) is a curated collection of websites, tools, and platforms in the OpenClaw and AI agent ecosystem. The directory is designed for readers who need a practical shortlist: tools to test, categories to browse, examples to compare, and source links to verify before making a workflow decision.
We believe the OpenClaw community benefits from a central map of tools, projects, and workflow ideas. That is why ClawSites keeps category pages, listing pages, guide pages, and submission instructions in one place. Votes and metadata help with discovery, but readers should still verify official documentation, pricing, and security details before installing or adopting a tool.
Why ClawSites?
Discover Tools
Find OpenClaw sites, agent tools, and automation platforms in one curated directory.
Stay Updated
New tools and sites are reviewed as the ecosystem changes.
Community Driven
Anyone can submit their OpenClaw tool or site. Built by the community, for the community.
Open Directory
A public directory for OpenClaw, AI agent, and automation resources.
Developer Friendly
Public skill files and API routes help builders understand how submissions work.
Launch & Grow
Submit your project so people researching agent workflows can discover it.
Quality Curated
Submissions are reviewed for clear descriptions, working links, and useful categorization.
Community Votes
Votes and listing metadata help readers sort options, but official sources remain the authority.
How the Directory Should Be Used
ClawSites is a discovery layer, not a replacement for official documentation. A listing can help you understand what a tool claims to do, which category it belongs in, how the community has interacted with it, and which related pages are worth reading next. The final decision should come from testing the tool against a narrow workflow and confirming current facts at the source.
This matters because agent tools often sit close to sensitive systems: browsers, files, messages, calendars, APIs, repositories, and customer data. A helpful listing should move a reader toward better questions. What can the tool access? What action does it take? What evidence remains after a run? Who approves the result? What happens when the input is incomplete or the tool fails?
The directory is most valuable when it keeps those questions visible. A submitted tool does not need to solve every workflow. It should explain one useful job clearly enough that a reader can decide whether to test it, compare it with alternatives, or skip it for now.
| Directory signal | What it tells you | What to verify next |
|---|---|---|
| Category | The type of workflow the tool is most likely to support. | Check whether the official website describes the same use case and supported integrations. |
| Description | The submitted summary of what the tool does. | Look for setup docs, examples, changelogs, or screenshots that support the claim. |
| Votes | A lightweight community signal that can help with sorting. | Do not treat votes as proof of security, reliability, or fit for your workflow. |
| Outbound link | Where to confirm current product facts. | Review pricing, permissions, account requirements, and source documentation before adopting. |
/// REVIEW FRAMEWORK
How to evaluate ClawSites directory research before you rely on it
Use this page as an orientation layer, then verify the current product details from the source that owns the tool or project. Directory research should help readers compare tools, but it should also make clear when current product facts need to be verified at the source. A good evaluation starts with one concrete workflow, not a broad promise that an agent can handle everything. The first workflow should be small enough to review by hand and realistic enough to expose the setup, permission, and output issues that matter in daily use.
The strongest OpenClaw-related tools make the operating boundary visible. A reader should be able to tell what data the tool reads, what system it can write to, how a person approves risky actions, and what evidence remains after the run. If a tool cannot explain those basics, keep it in a sandbox, use public or disposable data, and avoid connecting sensitive accounts until the behavior is clear.
| Area | What to verify | Why it matters |
|---|---|---|
| Workflow boundary | Write down the trigger, inputs, allowed actions, output, and human approval point before testing a tool. | A narrow boundary makes the first run easier to judge and reduces the chance of granting broad access too early. |
| Permissions | Check which files, browser sessions, inboxes, APIs, credentials, calendars, or messaging channels the workflow needs. | Agent workflows become risky when access grows faster than review, logging, and rollback practices. |
| Evidence | Prefer runs that leave a transcript, trace, screenshot, citation list, pull request, ticket, or structured output. | Evidence lets a user inspect what happened, repeat useful work, and diagnose failures without guessing. |
| Failure handling | Test incomplete inputs, changed pages, missing permissions, rate limits, and ambiguous instructions. | Reliable tools show partial results or ask for help instead of pretending the task succeeded. |
| Official source check | Confirm install commands, supported channels, security defaults, pricing, and current availability from official docs. | OpenClaw and adjacent agent tools change quickly, so evergreen directory copy should not replace source documentation. |
Listing review
Test this scenario with limited access first. Record the setup time, output quality, review effort, and failure mode before deciding whether the workflow deserves a larger role.
Category comparison
Test this scenario with limited access first. Record the setup time, output quality, review effort, and failure mode before deciding whether the workflow deserves a larger role.
Submission quality
Test this scenario with limited access first. Record the setup time, output quality, review effort, and failure mode before deciding whether the workflow deserves a larger role.
Compare tools by the work they complete, not by the most impressive demo. One option may be better for local control, another for browser automation, another for messaging, and another for team review. The right choice is the one that completes the target job with the least risky access and the clearest path for a person to approve or correct the result.
ClawSites helps turn broad OpenClaw research into a shortlist. Use the directory to discover related tools, then keep source links, current docs, and real test outputs in the decision record. That habit keeps the evaluation useful even when a project changes its installer, supported integrations, security defaults, or pricing model.
When the page describes commands, channels, or implementation details, treat them as a starting point that should be checked before installation. For production use, prefer a separate test account, a non-production workspace, scoped credentials, and a review step before sending messages, spending money, modifying files, deploying code, or connecting private data.
The review should also include a maintenance question: who will notice when the tool, model provider, API, browser flow, or messaging platform changes? Many agent projects work well during a first demo but become fragile when upstream documentation, authentication, selectors, rate limits, or pricing policies shift. A dependable OpenClaw workflow needs a responsible reviewer, a retest interval, and a fallback path that keeps the job moving when automation is paused.
That fallback can be simple: a manual checklist, a direct API call, a script, or a documented handoff to a teammate. Naming it in advance keeps the workflow usable when automation is unavailable and prevents a directory recommendation from becoming a single point of failure.
What to record after the first run
A short decision record makes agent evaluation repeatable. Record the date, the tool version or source page checked, the account used, the input provided, the output received, and the exact point where a person approved or stopped the workflow. This does not need to be formal documentation; a simple note is enough to prevent the team from relying on memory or a one-off demo.
Include the failure mode even when the test looks successful. For example, note whether the tool needed extra context, skipped a step, produced unsupported claims, required broad permissions, or returned a result that had to be rewritten. Those details are often more useful than the final answer because they show how much review effort the workflow will need after the first week.
Revisit the decision when the workflow, team, or tool changes. A setup that is acceptable for one user with sample data may need stronger permissions, logging, or approval controls before it fits a team process. A tool that is not ready for autonomous execution may still be useful for drafting, research, monitoring, or preparing artifacts for a human reviewer.
Keep
Use the tool again when it saves time, produces reviewable evidence, and needs only the access the task requires.
Limit
Restrict the workflow when output quality is useful but permissions, failure handling, or review cost still need work.
Skip
Avoid the tool for this job when a script, direct API, checklist, or manual review path is simpler and safer.
If the test involves another person, document the handoff as well as the agent output. The reviewer should know what the tool attempted, which source or account it used, what remains uncertain, and what action is still waiting for approval. That handoff is where many agent workflows either become dependable or create hidden work for the next person.
A good final decision is specific: keep the tool for one named workflow, limit it to assisted drafting or research, or skip it until the product exposes better controls. Avoid vague outcomes such as "promising" or "interesting" unless they are paired with the next test to run. Specific decisions make the directory useful for future readers because they connect discovery to a repeatable adoption path.
For higher-risk work, add one more line to the record: what must stay manual. That might be sending the final message, approving a purchase, merging code, changing customer data, or connecting a private account. Naming the manual step keeps the workflow honest and makes it clear where the agent is assisting rather than operating without review.
If the manual step feels hard to define, the workflow is probably not ready for broader access yet. Keep the tool in discovery mode until that boundary is clear.
For Developers & Creators
Are you building something for the OpenClaw ecosystem? We want to feature your project! ClawSites is an OpenClaw directory for discovering new tools, and getting listed can help readers who are already comparing agent workflows find your project.
Whether you have built an OpenClaw automation platform, a developer utility, a guide, a connector, or another useful resource, submit it with a clear workflow description. The strongest listings explain what the tool does today, what setup is required, and what a user should verify before relying on it.
Frequently Asked Questions
What is ClawSites?
ClawSites is an unofficial directory for OpenClaw tools, AI agent resources, workflow examples, and automation platforms. It helps readers move from broad research to a shortlist of tools they can verify and test.
Is ClawSites official?
No. ClawSites is an independent directory. Product documentation, official project websites, repositories, pricing pages, and security notes should be treated as the source of truth for current product details.
How do I submit my site?
Use the submit button on the homepage and provide a working URL, clear description, category, and enough context for reviewers to understand the workflow. Claims should be specific and easy for users to verify.
How are listings reviewed?
Listings are reviewed for basic quality signals such as a reachable website, understandable description, useful category, and relevance to OpenClaw or adjacent AI agent workflows.
How should readers use the directory?
Use ClawSites for discovery and comparison, then check the official product source before installing, connecting accounts, or relying on a tool for production work.
Is there a cost to submit?
Public directory submission is intended to be accessible. If featured or commercial listing options are introduced, those should be described separately from standard submissions.