platform/todo/integrations/openseo-a-plugin-candidate.md

id, title, theme, status, created, date_source, order

id	title	theme	status	created	date_source	order
integrations/openseo-a-plugin-candidate	OpenSEO — a strong plugin candidate, checked rather than assumed	integrations	open	2026-08-27	stated	1

OpenSEO (every-app/open-seo) — worth building a plugin around. Asked to be evaluated 2026-08-27; checked against gitea rather than taken on the README's word.

What it is: a self-hosted, open-source alternative to Semrush/Ahrefs — keyword research, rank tracking, competitor insights, backlinks, site audits, AI visibility. MIT licensed, TypeScript, 14.4k stars, 1.7k forks, pushed 3 days ago (verified via gh repo view, not the README's own framing) — a real, active project, not an abandoned demo.

Why it fits this platform specifically, more than most tools would: it ships its own MCP server and Agent Skills, built explicitly to be driven by "Claude Code, OpenClaw, or Hermes." That is Officer's whole plugin thesis already built by someone else — most candidates need Officer to invent the agent-facing surface; this one already has one.

The self-hosting shape is the easy case, verified from compose.yaml and the docs, not assumed:

• One container, no separate database. Cloudflare D1 (SQLite) by default — Postgres is opt-in only for installs that outgrow it (docs/LOCAL_POSTGRES.md). Same shape as Jellyfin, Gitea, Transmission: a single sidecar, nothing extra to provision.
• One required credential: a DataForSEO API key, paid pay-as-you-go DIRECTLY to DataForSEO — not a subscription to OpenSEO itself unless using their hosted version. Two more are optional (OpenRouter for its own AI features, Google OAuth for Search Console). Real cost, worth saying plainly: this is free software over a metered API, not a free service.
• Self-hosting runs AUTH_MODE=local_noauth by design — their own docs say explicitly "only expose it behind your own auth-protected reverse proxy, tunnel, or private network." That sentence describes exactly what an Officer plugin already is: mounted behind Officer's own permission gate, never exposed on its own. This is the ordinary case for a plugin here, not a special risk to design around.

What a plugin would actually need to add, and it may be less than usual: because OpenSEO already runs its own MCP server, the plugin's job is closer to credential plumbing and a UI surface (osDependencies-style container/sidecar, the DataForSEO key in the per-user/server credential store, a panel embedding or proxying its web UI) than inventing new MCP tools from scratch — most of the agent-facing work is already done upstream.

Open, for whoever picks this up: whether Officer's agents call OpenSEO's own MCP endpoint directly (simplest, if reachable over whatever network the plugin runs on) or Officer wraps it as Officer-native MCP tools for consistency with how other plugins expose theirs; and where the container runs given todo/infra/opm-officer-s-own-process-manager is heading toward the Docker network specifically so container-backed dependencies like this one need no published host port.