Tools & Integrations
Ready-made capabilities an agent can call: search, code execution, file handling and service integrations.
9 projects
OpenClaw installs a Gateway on your own machine and makes it the local control plane for sessions, tools, events and channel connections, so the Control UI, CLI, TUI and every connected messaging channel drive the same assistant. Models can be hosted or local, and the project expects new capabilities to arrive as plugins built on the plugin SDK rather than as changes to the core. The constraints are stated plainly in the README: it is designed for a single operator, tools run on the host for the main session unless you configure sandboxing, and DM-capable channels leave the assistant reachable by unknown senders until you approve a pairing with `openclaw pairing approve <channel> <code>`. The README tells you to read the security, exposure and sandboxing guides before connecting other users or exposing the Gateway remotely, which is a fair signal that shared or multi-user deployment is not the case it was built for.
Hermes Agent is Nous Research's own agent: a terminal UI plus a single gateway process that carries the same conversation into Telegram, Discord, Slack, WhatsApp, Signal and Email, with a cron scheduler, isolated subagents, and seven terminal backends from local and Docker to Modal and Vercel Sandbox. Its distinguishing piece is a closed learning loop — the agent curates its own memory on periodic nudges, creates skills after complex tasks, and searches past sessions through FTS5 with LLM summarization — which means the state that makes it useful accumulates under `~/.hermes`, outside your version control, and needs occasional pruning. It is an assistant you run and configure rather than a library you build on: the README documents `hermes` subcommands and slash commands, not an embedding API, so it is a poor fit if you wanted an agent loop to call from your own code. Putting a shell-capable agent behind chat platforms also makes the command-approval and DM-pairing settings load-bearing rather than optional.
Wires hundreds of services together on a visual canvas, and increasingly places LLM agents inside those flows. The licence is the thing to check first: it is source-available under the Sustainable Use License, not OSI-approved open source. Internal use and self-hosting are fine; reselling it as a hosted service is not.
Its real value is coverage: whatever model, vector store or API you need, an adapter probably already exists, which shortens the distance from idea to prototype. The abstractions have a reputation for indirection, so many teams use it for the integrations and reach for something more explicit once the control flow gets complicated.
Extracts the interactive elements of a page and hands the model a structured list, instead of asking it to guess click coordinates from a screenshot. That makes it markedly more reliable for form flows and scraping. It degrades on canvas-heavy applications and on sites with aggressive bot protection, where there is no clean DOM to read.
The clearest way to understand the Model Context Protocol is to read servers that implement it correctly, and this is that collection. Useful both as working connectors and as the template to copy when writing your own.
Over a hundred skill directories of Google's own written guidance, installed selectively with `npx skills add google/skills`. The bulk sits under `skills/cloud` — GKE, BigQuery, Agent Platform, the six Well-Architected pillars — while `skills/ads` and `skills/analytics` cover the Google Ads API, the Mobile Ads and IMA SDKs and the two Google Analytics APIs. Depth is uneven: `skills/cloud/gke-*` accounts for twenty-nine directories on its own, Cloud Run and Firebase get one each, and the README labels the repository as under active development. A stack on neither Google Cloud nor Google's ads and analytics products gets nothing here, and app-side coverage stops at the Mobile Ads SDK — Android, Flutter, Dart, Genkit and ADK skills are separate repositories the README only links to.
`npx @openai/codex-security scan .` walks a checkout and leaves JSON results on stdout, while `--mode deep` spreads discovery across workers and subagents until it stops turning up anything new. Across runs, `scans compare BEFORE_SCAN_ID AFTER_SCAN_ID` matches findings by root cause and labels them new, persisting, reopened, resolved or unknown, so a second scan reports movement instead of restating the whole report. It is a poor fit as a pre-commit gate: deep discovery runs until `--max-time-hours`, which defaults to 96. Access is also gated — the CLI needs access to Codex Security, and some cybersecurity requests and protected findings require Trusted Access for Cyber approval, so cloning the repo on its own scans nothing.
numbat is a single binary that watches supported desktop, CLI, IDE and gateway agents through hooks, plugins and OTLP/HTTP log exporters, normalizes their activity into one event model, and evaluates it with a local CEL rule engine that writes versioned NDJSON events, findings and enforcement decisions. It also reconstructs past sessions from on-disk artifacts via `numbat scan`, so you can investigate an agent that was never instrumented. Blocking is deliberately conservative: enforce mode is off by default and every shipped rule is monitor-only, so denying an action means copying the rule YAML into your own `--rules-dir`, keeping its id, adding `enforce: true` and bumping the version. It is a poor fit if you expect coverage of arbitrary agents or a definitive account of what ran — the coverage matrix decides what is observable per host and surface, at-rest reconstruction cannot recover activity an agent never persisted, and findings are rule matches rather than proof that an action completed.