Open-source SEO agent for link building. Plans campaigns and builds backlinks from Claude, Cursor or Codex via MCP. 1,245-site library.
SEO Agent has 9 tools with schemas and descriptions present, but quality is inconsistent. Tool names follow verb_noun convention (search_sites, get_method, build_link, verify_link, log_link, activate, plan_campaign, results). However, descriptions are often vague or domain-specific jargon-heavy without explaining WHEN to use each tool or WHAT the LLM should expect. For example, search_sites description mentions 'locked examples' and 'teaser' concepts without defining them for an LLM unfamiliar with the SEO domain. Parameters have types and basic descriptions, but lack constraints (enums, ranges, patterns). Output schemas are not documented, the code shows what's returned but the tool definitions don't declare expected response structure. Error handling is minimal; no recovery guidance or actionable error messages visible. Security concern: activate() accepts an API key as a parameter, violating secret-injection pattern.
Activate a subscription with an API key to unlock the full library and hosted engine.
Build one link in a local browser on a login-free site. Elsewhere returns the method to follow.
Get the method details for a specific site including playbook and rules for building a link.
Get summary statistics about the link library: free sites count, DA range, subscription details.
Log a link placement result to the local results database.
Plan a link building campaign: choose sites, methods, and targets based on search criteria.
Get the log of all link placements and their status.
API key exposed as tool parameter in activate(). Credentials must use server-side secret injection via environment variables, not tool parameters. Agent traces log all parameters, secrets leak into logs and prompt history.
Descriptions lack WHEN/WHY guidance. search_sites mentions 'locked examples' and 'teaser' without explaining these concepts to an LLM unfamiliar with SEO domain. Descriptions should state what the tool does, when to use it vs similar tools, and what it returns.
No output schemas documented. Code shows what each tool returns (e.g., search_sites returns {free, free_total, locked_examples, full_library, upgrade, ask_the_user}), but tool definitions do not declare expected response structure. LLMs cannot plan downstream calls without knowing output fields.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | D | 58 | 2026-07-28+ | v2 |
Free matches with their methods, then what the full library holds for the same search: up to five locked examples by name and DA, and the counts. The locked part is how the assistant knows when to offer the upgrade.
Verify that a link exists on a live page with the correct target URL and anchor text.
Parameters lack constraints. No enums for status values in log_link (placed|unverified|manual|failed), no ranges for min_da or limit, no patterns for URLs or anchor text. Free-form strings invite hallucinated values.
No error recovery guidance. If a tool fails (e.g., build_link fails to place a link, activate fails with invalid key), the response does not tell the LLM what to do next. Error messages should be actionable: 'Invalid API key. Verify the key from your subscription email and try again, or call search_sites() to see free options.'