Skip to main content
Glama
manmohm

advisorsai-check (Advisors AI)

advisorsai-check

Listed on mcpservers.org AI page readiness skills.sh

Does a public page expose the declared machine-readable basics that answer engines can use?

One command. No API key, no account, no signup.

One click inside your agent (GitHub strips cursor:// links — use the live buttons): https://advisorsai.ai/see.html

npx skills add manmohm/advisorsai-check
/plugin marketplace add manmohm/advisorsai-check

Share a measured page (SSL Labs pattern): https://advisorsai.ai/see.html?url=https://example.com

# one-off, nothing left behind (needs pipx: python -m pip install pipx)
pipx run --spec git+https://github.com/manmohm/advisorsai-check advisorsai-check example.com

# or install once
pipx install git+https://github.com/manmohm/advisorsai-check
advisorsai-check example.com
git clone https://github.com/manmohm/advisorsai-check.git
cd advisorsai-check
python -m pip install .
advisorsai-check example.com

Use it from Claude or any MCP client — no install

The same bounded public-page check is available as one remote, read-only MCP tool. You provide one public URL; it returns at most one actionable finding with an HMAC evidence receipt that the operator can re-verify.

The remote tool does not write to the submitted site, store the result, share it, infer answer-engine rankings, or predict sales. It is new: there are no customer case studies yet.

advisorsai-check  https://example.com

  ok   page title: «Example — industrial valves since 1994»
  ok   meta description, 153 chars
  MISS no Organization/LocalBusiness structured data: nothing states what this
       business IS in a form machines read
  MISS no Service/Product structured data: what you sell is only in prose
  ok   one <h1>: «Valves that survive the plant floor»
  ok   canonical link with an HTTP(S) href is present
  ok   declared robots policy allows search crawlers on /
       (training/model-use crawlers blocked by policy: GPTBot, Google-Extended)
  note no /llms.txt (informational only: it is not a web standard)
  ok   valid urlset sitemap with 24 locations

  64% of the declared public-page basics checked in this run are in place.

Related MCP server: aeo-mcp

Run the public-page basics MCP locally

From a source checkout, install the optional MCP dependency with Python 3.10+:

python -m pip install ".[mcp]"
advisorsai-public-page-mcp
# equivalent: python -m advisorsai_check.mcp_stdio

The process speaks MCP over stdin/stdout and waits for a client. It exposes advisors_public_page_basics_check(url), which calls the same bounded public advisorsai_check.run library used by the CLI. Its English report contains url, success, score, coverage_percent, unchecked_count, signals and errors. Each signal contains key, ok, detail, weight and evidence. An incomplete run keeps the library's score: null; coverage is reported separately. As in the CLI, returned text has terminal control channels removed and whitespace normalized; it remains untrusted data. The returned normalized URL retains its query string, so submit a URL that is safe to show in the MCP client.

This portable mode needs no account, API key or HMAC material. It fetches only the supplied public origin through the existing checker's network safeguards. It does not proxy to Advisors AI, issue an HMAC receipt, or provide the official remote tool's one-finding capsule or Arabic/English language option. The official remote receipt-producing mode above remains available separately. Neither mode measures answer-engine rankings, mentions or sales.

For a local MCP client:

{
  "mcpServers": {
    "advisorsai-public-page-basics": {
      "command": "advisorsai-public-page-mcp"
    }
  }
}

Use it as an Agent Skill

npx skills add manmohm/advisorsai-check

Coding agents that follow the Agent Skills format can load SKILL.md at the repo root (GitHub topic ai-skill) or skills/ai-site-readiness/SKILL.md: they teach the agent to run this check, read only observed evidence, and never claim rankings.

Embed the live checker on another README:

[![AI page readiness](https://advisorsai.ai/badge/ai-readiness.svg)](https://advisorsai.ai/see.html)

What it checks

Signal

Why a machine cares

robots.txt

The site's declared policy for autonomous search crawlers on the submitted path. User-triggered fetchers and training/model-use crawlers are reported separately and never change the score. It does not prove a crawler passes the site's firewall.

llms.txt

An experimental summary. It is reported but carries no score weight: it is not a web standard, and Google Search says it does not use it.

JSON-LD Organization

Whether anything states, in a form machines parse, what this business is.

JSON-LD Service / Product

Whether what you sell exists outside prose.

<title>, meta description, <h1>, canonical

Page fields commonly exposed to parsers.

sitemap.xml

Whether /sitemap.xml has valid urlset/url/loc or sitemapindex/sitemap/loc records with absolute HTTP(S) locations.

What it does not check

It does not tell you whether an assistant names you when a buyer asks.

That is not established by a page fetch. It is an observation of live answers, and establishing it requires timestamped captures against real assistants and comparison with peers. This tool therefore never relabels its bounded page checks as a visibility score.

So everything here is a public-page basic: a fixable technical condition, not evidence that an answer engine will cite you. Not a ranking. Not a share. Not a promise.

Install from source

git clone https://github.com/manmohm/advisorsai-check.git
cd advisorsai-check
python -m pip install .
advisorsai-check example.com

The package is not yet published to PyPI. Do not use or advertise a pip install advisorsai-check command until the release exists there. The package requires Python 3.10+, including the command-line checker and optional MCP dependencies. The local stdio adapter above is portable. The published official remote-server source is for inspection of its operator deployment rather than a turn-key receipt-producing self-hosted promise. The package pins html5lib==1.1 and webencodings==0.6.1 so malformed HTML is interpreted with one stable HTML5 tree-construction contract and charset labels follow the WHATWG web-encoding registry. The HTML parser and fact extractor run in a byte-capped, time-capped child process; there is no hand-written token or nesting estimator. Home pages must be served as text/html: application/xhtml+xml is deliberately rejected because this tool does not claim an XML parsing contract. Responses must also be an uncompressed identity representation; unsupported Content-Encoding values are rejected instead of being parsed as HTML bytes.

Use it in CI

GitHub Action (Ubuntu runner):

- uses: manmohm/advisorsai-check@main
  with:
    url: https://example.com
    min-score: "80"

--json gives you the full result. Exit code 0 means every checker returned; 1 means at least one check was unavailable or failed internally; and 2 means the submitted address was unusable. A partial run publishes score: null, reports weighted coverage_percent, and is never a successful process result:

set -o pipefail
advisorsai-check example.com --json | jq '.score'
- name: Public-page machine basics
  run: |
    git clone --depth 1 https://github.com/manmohm/advisorsai-check.git /tmp/advisorsai-check
    python -m pip install /tmp/advisorsai-check
    result=$(advisorsai-check "$SITE" --json) || {
      status=$?
      echo "$result"
      exit "$status"
    }
    score=$(printf '%s' "$result" | jq -er '.score')
    echo "Declared public-page basics: $score%"
    [ "$score" -ge 80 ] || { echo "::warning::below 80%"; }

As a library

from advisorsai_check import run

report = run("example.com")
if not report.successful:
    raise RuntimeError(report.errors)
print(report.score)
for signal in report.signals:
    if signal.ok is False:
        print("fix:", signal.detail)

report.successful is false if any signal is unchecked or any checker raised an internal error. In that state report.score is None; use report.coverage_percent to describe how much of the weighted check set ran, never as a substitute score. The report vocabulary is closed: every run carries exactly one receipt for home, title, description, structured_business, structured_offering, h1, canonical, robots, llms_txt, and sitemap, with weights fixed by the library. jsonld_valid is the sole optional diagnostic and may occur at most once. Missing stages, unknown keys, duplicates, empty receipts, or changed weights make the report unsuccessful; they can never yield a score or 100% coverage. The home receipt also pins the six page-derived rows: a checked home failure requires checked failures for title, description, structured business, structured offering, H1, and canonical; an unavailable home requires all six to remain unavailable. The optional jsonld_valid row is accepted only as a negative diagnostic (false) after a full home representation was parsed. It can lower a score but can never act as a positive bonus. Although home and llms_txt are zero-weight stage receipts, leaving either unchecked adds a missing-coverage unit, so a partial run cannot display 100% coverage. signal.ok is True, False, or None. None means the check could not run — a DNS, connection, TLS, or timeout failure, for example. Such failures are reported as unchecked (ok: null), never as evidence that the site failed. They make the whole run incomplete: report.successful is false, report.score is None, and coverage_percent shows only the weighted share that actually ran. Status 0 is reserved for this transport/unavailable state. An HTTP 4xx or 5xx response is different: the site did answer, so it produces a checked result according to that signal's contract before the checker considers the error representation's body or Content-Type. Thus a home-page 4xx/5xx is a checked failure even when the body is empty or mislabeled; robots.txt keeps RFC 9309's distinct 4xx/5xx semantics. A page or robots representation is full only at exact HTTP 200: informational/accepted or partial/delta statuses such as 202, 206, and 226 are rejected. Redirects to another origin are not followed.

The first site we pointed it at was our own

It identified a crawler-policy mismatch between the site's intended robots rules and the rules served at the edge. The lesson is narrower than a ranking claim: inspect what public crawlers actually receive, not only the file in the repository.

We had not noticed. The tool found it in one run, which is the entire argument for running it on yours.

Who made this

Advisors AI measures timestamped answer-engine outputs for a business, and builds systems the client then owns outright. This tool is the free, honest part: the part you can verify yourself, offline, with the source in front of you.

The paid part is the part this tool refuses to guess at — what assistants actually say about you, with the captures to prove it, and what to change.

MIT licensed. Issues and pull requests welcome.

Available Tools

1 tool
advisors_public_page_basics_checkCheck one public page's declared machine-readable basicsA
Read-onlyIdempotent

On explicit request, fetch one credential-free public HTTP(S) page and its same-origin robots.txt, sitemap.xml and llms.txt. Return the library's signals, completeness, coverage and score (null if incomplete). Private networks and non-standard web ports are rejected by the checker. No API key, HMAC receipt, ranking or answer-engine visibility measurement is provided.

NameRequiredDescriptionDefault
urlYesOne credential-free public HTTP(S) page or domain. A domain without a scheme uses HTTPS.

Output Schema

NameRequiredDescription
urlYes
scoreYesLibrary score for declared basics; null for incomplete runs.
errorsYes
signalsYes
successYesWhether the complete library check returned.
unchecked_countYes
coverage_percentYesLibrary coverage; not a substitute score.

TDQS

A4.3/5.0
Behavior4/5

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

Beyond the annotations, the description discloses meaningful behavior: same-origin fetching of robots.txt, sitemap.xml and llms.txt, rejection of private networks and non-standard web ports, and the absence of API keys, HMAC receipts, ranking or answer-engine visibility measurement. This adds useful scope and limitation context, though it does not mention rate limits or missing-file behavior.

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?

The definition is two tightly packed sentences that front-load the trigger condition and primary action. Every clause adds either scope, output, or limitation information without 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?

An output schema exists, so return-value details need not be fully repeated, and the annotations already establish the safety profile. The description supplies the remaining critical context: what is fetched, which network targets are rejected, and which related capabilities are explicitly not provided.

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

Parameters3/5

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

Schema description coverage is 100%, and the single url parameter is already documented with examples and the HTTPS default behavior for domains without a scheme. The description does not add parameter-specific meaning beyond the schema, so the baseline 3 is appropriate.

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?

The description uses a specific verb (fetch) and precisely names the resource: one credential-free public HTTP(S) page plus its same-origin robots.txt, sitemap.xml and llms.txt. It also states the returned artifacts (signals, completeness, coverage, score), making the tool's purpose unmistakable.

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

Usage Guidelines4/5

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

It clearly scopes usage with 'On explicit request' and 'credential-free public HTTP(S) page', and explicitly excludes private networks and non-standard web ports. There are no sibling tools to route between, so no alternative-tool guidance is needed, but it does not specify when not to use the tool beyond those network restrictions.

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

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

  1. 1 tool updatev1.1.0
    • First observedadvisors_public_page_basics_check

TDQS

A4.2/5.0

Scored across 1 tool

Disambiguation5/5

Only one tool exists, so there is no possibility of confusing it with another. Its purpose—fetching a single public page plus robots.txt/sitemap.xml/llms.txt and scoring library signals—is explicitly stated.

Naming Consistency4/5

The single name is descriptive snake_case with a namespace prefix (advisors_) and a clear action suffix (check), which is readable and predictable. With only one tool there is no pattern to verify, so it falls just short of a 5.

Tool Count4/5

For a narrowly scoped public-page audit checker, a single tool is defensible and each capability is bundled coherently. It is still on the thin side (1 tool), leaving no room for complementary operations.

Completeness3/5

It covers the stated single-page fetch-and-score workflow including robots/sitemap/llms retrieval, but the surface is a dead end: no batch checks, no multi-page crawl, no history or comparison, and no follow-up actions. Agents needing anything beyond one page check will be blocked.

Maintenance

ActivitySlowing
ResponsivenessNo issues

Related MCP Connectors

Related MCP Servers

  • A
    license
    A
    quality
    D
    maintenance
    Enables AI agents to perform comprehensive SEO audits on web pages, including meta tags, headings, links, images, performance, and more, via a CLI or MCP server.
    18
    1
    MIT
  • A
    license
    A
    quality
    D
    maintenance
    An MCP server that gives AI agents tools to inspect a website's visibility to AI answer engines, including crawler permissions, llms.txt, structured data, on-page signals, and a full 29-check AI-readiness audit.
    5
    11 npm
    MIT
  • A
    license
    Not graded
    quality
    D
    maintenance
    Open-source MCP server that audits websites for AI search readiness, providing deterministic scoring (0-100) and prioritized fix lists for metrics like JSON-LD, llms.txt, heading hierarchy, and AI crawler access.
    1
    MIT
  • A
    license
    A
    quality
    A
    maintenance
    An MCP server that lets an AI agent audit a page for SEO and GEO — on-page tags, structured data, robots.txt, sitemaps, hreflang, and whether ChatGPT, Claude, Perplexity and Gemini can actually crawl and cite you. No API keys required.
    17
    261 npm
    1
    MIT