Skip to main content
Glama
kienpt91

founder-toolkit-mcp

by kienpt91
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

SEOBolt focused checker

seo_check
Read-onlyIdempotent

Run one focused SEO or AI-search readiness check on a domain or page, returning verdicts and fix guidance for issues like robots.txt, sitemaps, meta tags, or structured data.

Instructions

Run ONE focused SEOBolt checker against a public domain or page (sends the target to seobolt.app). Use after seo_free_audit points at an area, or when the user asks about one specific thing (llms.txt, robots, sitemap, meta tags, structured data...). Input: tool plus target. Domain checkers want a domain; page checkers want a page URL. Returns verdict, pass/warn/fail counts and per-check detail with fixes. Rate limit: anonymous, roughly 3-10 calls per 5 minutes per IP depending on the checker. On a rate-limit error stop and tell the user; do not loop. Checkers:

  • llms-txt-checker (domain): Is there a valid /llms.txt (and optional llms-full.txt)?

  • ai-crawler-access-checker (domain): Does robots.txt let AI search and user-request crawlers reach the site?

  • chatgpt-visibility-checker (domain): Can the crawlers behind the most widely used chat assistant reach the site, plus on-page signals for being cited?

  • ai-citation-readiness-checker (url): Does a page carry the signals answer engines use to quote it (12 signals)?

  • redirect-checker (url): Follow the redirect chain of a URL and flag loops, long chains, http->https.

  • indexability-checker (url): Can search engines index the page (status, noindex, X-Robots-Tag, canonical)?

  • sitemap-checker (domain): Find and validate the XML sitemap.

  • structured-data-checker (url): Find and validate JSON-LD structured data on a page.

  • heading-structure-checker (url): Check H1 count and heading hierarchy on a page.

  • broken-link-checker (url): Check links found in the page's served HTML for broken or redirecting targets.

  • meta-tag-checker (url): Title, description, canonical, Open Graph and Twitter tags with length checks.

  • robots-txt-tester (domain): Fetch robots.txt and test whether named bots may crawl given paths (optional bots and paths).

Input Schema

NameRequiredDescriptionDefault
botsNorobots-txt-tester only: user-agent names to test.
toolYesWhich SEOBolt checker to run.
pathsNorobots-txt-tester only: paths to test, each starting with '/'.
targetYesDomain (example.com) for domain checkers, or full page URL (https://example.com/page) for URL checkers. A URL is reduced to its host for domain checkers; a bare domain becomes https://<domain>/ for URL checkers.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A4.8/5.0
Behavior5/5

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

Annotations already cover the safety profile (readOnly, idempotent, openWorld, non-destructive), but the description adds material context beyond them: the target is sent to a third-party host (seobolt.app), the anonymous rate limit of roughly 3-10 calls per 5 minutes per IP, and the exact response shape (verdict, pass/warn/fail counts, per-check detail with fixes).

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

Conciseness4/5

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

Front-loaded with the one-sentence purpose, then input, return, rate limit, and the checker catalogue. The catalogue is long but each line disambiguates an enum value, so it earns its space; the structure could be tightened but nothing is truly wasteful.

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?

For a multi-mode tool with four parameters and no output schema, the description covers what to pass, which mode wants which target form, what comes back, and how failures behave. An agent has everything needed to pick a checker and call it correctly.

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

Parameters4/5

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

Schema coverage is 100%, so the baseline is 3; the description earns extra by mapping each `tool` enum value to whether it expects a domain or a page URL, which the enum itself does not state. It does not repeat the coercion rules for `target` or the `bots`/`paths` constraints, which live in the schema.

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?

States a specific verb and resource ('Run ONE focused SEOBolt checker against a public domain or page') and enumerates the twelve checkers with one-line scopes. It also distinguishes itself from the sibling seo_free_audit by positioning itself as the narrow, single-area follow-up rather than the broad audit.

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?

Gives explicit selection rules: 'Use after seo_free_audit points at an area, or when the user asks about one specific thing'. Each checker entry carries its own domain-vs-URL applicability, and the rate-limit sentence tells the agent exactly what to do on failure ('stop and tell the user; do not loop').

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