LLMScout

Overview Schema Source Related Servers Discussions Admin

run

Execute the llmscout CLI to scaffold SEO/GEO configs, audit a site's technical SEO and generative-engine optimization, or batch-check multiple sites, returning structured JSON.

Instructions

Run the llmscout CLI (published as llmscout-cli on npm and PyPI) and return its structured output as JSON. Call this to scaffold an SEO/GEO config for a local project, run llmscout's 21-check technical-SEO and generative-engine-optimization audit against a site, or batch-run that audit across a fleet of sites, without shelling out yourself.

Call it once you have a local project directory path, and for check/fleet a site that already has an llmscout.json (created by a prior init call, or already present in the project). Do not call check on a directory that has never been init-ed: it fails fast with a missing-config error rather than guessing a site URL. No API key or auth is required. check and fleet make live outbound HTTP requests to the target site(s) (the page itself, robots.txt, sitemap.xml, and related resources) so they need network access and will be slower or noisier against unreachable hosts; init only writes local files (a config and a small skill file) and makes no network calls. All subcommands are safe to re-run: init overwrites its scaffolded config, and check/fleet never write anything unless --out-dir is given, in which case a report file is rewritten each run. On failure (non-zero exit, bad args, unreachable site), the underlying process's stderr is captured rather than raised.

args is a list[str] of the CLI's own argv, split exactly as you would type it on a command line (never a single shell string), and should never include --json yourself since this wrapper appends it automatically. Real examples:

["init", "./my-site", "--site-url", "https://example.com"]
["check", "./my-site", "--out-dir", "./reports"]
["fleet", "./fleet.json", "--out-dir", "./reports"] Pass ["--help"] or ["", "--help"] (e.g. ["check", "--help"]) as args to discover the live, authoritative list of subcommands and flags.

Returns a dict. On success it is the parsed JSON the CLI printed: init returns the scaffolded config paths, check returns {siteUrl, summary: {pass, warn, fail, total}, results: [{id, name, category, status, message, fix?}, ...]}, and fleet returns one such result per site. On failure it returns {"error": ..., "stderr": ..., "command": ...} if the CLI exited non-zero, or {"error": ..., "stdout": ..., "command": ...} if stdout was not valid JSON; it never raises.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`args`	Yes

Output Schema

TableJSON Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

First observedv1.0.0Aug 10, 2026

TDQS

A5/5.0

Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are supplied, so the description carries the full burden and does so: it discloses auth requirements (none), network behavior per subcommand (init writes local files only; check/fleet make live HTTP requests), idempotency/re-run semantics, --out-dir write behavior, and the exact failure-return shape including stderr capture instead of raising.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Long but tightly organized: purpose, preconditions, network/safety behavior, then arg semantics with examples, then return shape. Each paragraph carries distinct operational information with no filler or repetition.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the wrapper's complexity and 0% schema documentation, the description covers prerequisites, side effects, error handling, arg encoding, and even return structure. An output schema exists, yet the description still summarizes returns, which is harmless and clarifying.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 0% with a single param, so the description must compensate, and it does: it defines args as list[str] of argv split exactly as typed (never a shell string), forbids self-supplying --json, and gives three concrete example invocations plus the --help discovery path.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

Opens with a specific verb+resource ('Run the llmscout CLI ... return its structured output as JSON') and then names the three concrete operations (init scaffold, check audit, fleet batch). An agent can tell exactly what this tool does without additional context.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

States explicit preconditions ('call it once you have a local project directory path, and for check/fleet a site that already has an llmscout.json'), the negative case ('Do not call check on a directory that has never been init-ed'), and how to discover subcommands via --help. This is a full when/when-not/alternatives treatment.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Deploy Server

Other Tools

runA