Which integrations are available for this server?

Queries Perplexity as one of the answer engines to assess whether a website is visible to AI assistants.

How do I use INITE MCP?

1. Click on "Deploy Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@INITE MCP Can ChatGPT actually find stripe.com, or is it invisible?" That's it! The server will respond to your query, and you can continue using it as needed. Here is a step-by-step guide with screenshots.

INITE MCP

Official

by inite-ai

Overview Schema Source Related Servers Discussions Admin

TypeScript

Local

INITE MCP — AI visibility, from inside your agent

Ask your assistant whether the answer engines can see a website, and get a number back.

> Can ChatGPT actually find stripe.com, or is it invisible?

  analyze_site(url: "stripe.com")   → run_id: cm4x…
  get_analysis(run_id: "cm4x…")     → Score: 78/100

The audit reads a live site the way an assistant does — the identity files an engine looks for (llms.txt, ai.json and the rest), the crawler policy, the schema graph, page health — and then asks Claude, ChatGPT, Gemini and Perplexity whether they name it. One score out of 100 across eight weighted sections.

It is the same audit that runs at inite.ai/en/analyze.

Three of the tools run entirely on your machine — a robots.txt fetched, a file probed for, a page parsed. No account, no allowance, no call home.

> Is anything blocking AI crawlers on stripe.com?

  check_ai_access(url: "stripe.com")

  Retrieval: all 7 answer-engine crawlers may fetch the site.
  Training:  3 of 8 blocked — Meta-ExternalAgent, Bytespider, Amazonbot.

Signing in adds the two that cost something real: the answer engines are actually asked whether they name the site, and the eight weighted sections are scored.

Related MCP server: Accrue SEO

Install

Claude Desktop, Cursor, or any client that launches a stdio server:

{
  "mcpServers": {
    "inite": {
      "command": "npx",
      "args": ["-y", "@inite/visibility"]
    }
  }
}

Then sign in once:

npx @inite/visibility login

That opens a browser, you approve, and the token is stored at ~/.config/inite/mcp.json with owner-only permissions. Authorization code with PKCE over a loopback redirect, the flow RFC 8252 prescribes for a native app. Nothing is written to the repository and no secret ships in the package.

Already have a token (CI, a shared config, a container):

{
  "mcpServers": {
    "inite": {
      "command": "npx",
      "args": ["-y", "@inite/visibility"],
      "env": { "INITE_TOKEN": "…" }
    }
  }
}

INITE_TOKEN wins over the stored file.

Client speaks the MCP authorization flow? Skip this package. Point it straight at https://inite.ai/api/mcp and it will discover the rest: an unauthenticated call answers 401 with WWW-Authenticate naming the protected-resource metadata, which names the authorization server.

Tools

Local — no account:

tool	what it does
`check_ai_access(url)`	Which AI crawlers `robots.txt` lets in, separating the ones that fetch a page to answer a live question from the ones that only collect training data. Blocking the first kind is what makes a site invisible; blocking the second costs nothing.
`check_identity_files(url)`	Which of the ten identity files exist — `llms.txt`, `ai.json`, `identity.json` and the rest.
`check_page_signals(url)`	Title, description, canonical, hreflang, and the Schema.org types in the page's JSON-LD.

Remote — needs an account:

tool	what it does
`analyze_site(url)`	Starts the full audit and returns a `run_id`. Takes about a minute.
`get_analysis(run_id)`	Progress while it runs; the score out of 100 and the report address once it finishes.

Two tools rather than one for the audit, because it is asynchronous. A single tool that blocked for a minute would be torn down by most clients' timeouts.

Commands

inite-visibility            run as an MCP server over stdio (what a client does)
inite-visibility login      sign in through the browser
inite-visibility whoami     say whether a usable token is present

What this package is

Two halves.

The local checks are real work done here: fetching, parsing, and the robots rules applied properly — most-specific group wins, longest matching rule wins, Allow breaks a tie. They cost nobody anything because your machine does them.

The remote half defines no schemas of its own. It asks inite.ai what it offers and forwards calls there, so that tool list is whatever the service implements today. A local copy would be a second source of truth, and the first thing it would do is drift.

What stays on the server is what costs something or is ours: four answer engines asked whether they name a site, and the weights that turn everything into one number. The local tools report facts; analyze_site reports a score.

Account and allowance

An audit spends real work — fetches, and model calls across four answer engines — so it runs against an account rather than anonymously. The daily allowance and the depth of the report are your plan's own, exactly as on the website: a free account gets the teaser tier, a paid one the full pipeline. Plans are here.

Environment

variable	meaning
`INITE_TOKEN`	Use this token instead of the stored one.
`INITE_MCP_URL`	Point at a different endpoint. Default `https://inite.ai/api/mcp`.
`INITE_TOKEN_FILE`	Where the token lives. Default `~/.config/inite/mcp.json`.
`INITE_AUTH_URL`	Authorization server. Default `https://auth-api.inite.ai`.

Namespace

Published to the MCP registry as ai.inite/inite-visibility, a namespace held by proving control of inite.ai — the public half of the key is served at /.well-known/mcp-registry-auth.

Named by the domain rather than the code host on purpose: a service whose whole job is being legible to machines should tell them who it belongs to in its own name.

A note on the command name

npx @inite/visibility resolves because there is exactly one binary in the package. npm looks for a command matching the package name with the scope stripped — visibility — does not find it, and runs the only one there is.

The binary is called inite-visibility rather than visibility on purpose: a scoped package has no business claiming a word that general in your PATH on a global install. The cost is that a second binary would break the line above for every client, so a test pins it at one.

If you are invoking it from a directory that contains this package's own package.json, npm prefers the local copy and finds no linked command. Name it explicitly there:

npx -p @inite/visibility inite-visibility login

Development

npm install
npm run build
npm test

The tests cover what the bridge can get wrong without saying so: dropping the credential, turning "signed out" into "broken", swallowing an error into a success, and letting a stale file beat the environment.

Licence

MIT. The service it talks to is INITE.

Available Tools

3 tools

check_ai_accessAInspect

Read a site's robots.txt and say which AI crawlers may fetch it, separating the ones that retrieve pages to answer live questions from the ones that only collect training data. Blocking the first kind is what makes a site invisible in AI answers; blocking the second costs nothing. Runs locally, no account needed.

ParametersJSON Schema

Name	Required	Description	Default
`url`	Yes	A public site, e.g. example.com or https://example.com

TDQS

A4/5.0

Behavior4/5

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

With no annotations, the description carries the behavioral burden. It discloses that the operation is a read, that it runs locally, that no account is needed, and that it classifies crawlers into live-question and training-data categories. This is meaningful context, though edge cases like missing robots.txt are not discussed.

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 description is three focused sentences: it states the action, explains the meaningful distinction, and gives an operational note. Every sentence adds value and the main behavior is front-loaded.

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

Completeness4/5

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

For a simple one-parameter tool with no output schema, the description explains what the tool does and what kinds of results it produces. It could be more complete by describing output format or failure behavior, but the core agent decision and invocation need are well covered.

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?

The schema already covers the single 'url' parameter 100%, including an example. The description adds little parameter-specific meaning beyond contextualizing it as a site whose robots.txt is read, so the baseline of 3 applies.

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 states a specific verb-resource pair: 'Read a site's robots.txt' and 'say which AI crawlers may fetch it.' It clearly separates the tool from siblings by focusing on robots.txt + AI crawler classification, not identity files or page signals.

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

Usage Guidelines3/5

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

The description implies when to use the tool — when assessing AI crawler visibility — and even explains the practical consequence of blocking different crawler types. However, it does not explicitly mention alternatives or state conditions for when not to use it.

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

check_identity_filesAInspect

Probe a site for the identity files an AI engine may look for — llms.txt, ai.json, identity.json and the rest — and report which exist. Runs locally, no account needed.

ParametersJSON Schema

Name	Required	Description	Default
`url`	Yes	A public site, e.g. example.com or https://example.com

TDQS

A4.1/5.0

Behavior4/5

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

Despite no annotations, the description discloses key behavioral facts: it probes a site, runs locally, requires no account, and reports which files exist. This gives an agent a reasonable sense of the tool's operation and side effects, though failure modes and network behavior are not covered.

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?

Two compact sentences with the main action front-loaded and the operational constraints in a single clause. No filler or redundant restating of the tool name.

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 one-parameter probe tool with no output schema and no annotations, this is complete: it states what it checks, what it reports, and the access model. Nothing an agent needs to invoke it correctly is missing.

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 coverage is 100%, so the existing url parameter description already covers the only parameter. The tool description adds no parameter-specific detail, but none is really needed beyond what the schema provides.

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?

Clearly identifies a specific action (probe a site), a specific resource class (identity files for AI engines), and explicitly names examples. Enough to distinguish from check_ai_access and check_page_signals by the object being checked.

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

Usage Guidelines3/5

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

Provides supporting context ('Runs locally, no account needed') but no explicit when-to-use guidance or direction to sibling tools. An agent can infer the intended use from the tool name and description, but exclusion criteria are absent.

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

check_page_signalsAInspect

Read a site's homepage and report the signals an engine uses to work out what it is: title, description, canonical, hreflang and the Schema.org types in its JSON-LD. Runs locally, no account needed.

ParametersJSON Schema

Name	Required	Description	Default
`url`	Yes	A public site, e.g. example.com or https://example.com

TDQS

A4/5.0

Behavior3/5

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

With no annotations provided, the description must carry the behavioral disclosure. It does disclose that the operation runs locally, requires no account, and is read-only in nature ('Read... report'). But it does not mention potential limitations such as network requirements, redirect handling, or behavior when the homepage lacks certain signals. This is adequate but not comprehensive for a tool with zero annotation support.

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 description is a single well-structured sentence that front-loads the core action, then lists the exact signals, and ends with the deployment/access note. Every clause adds value, and there is no repetition of schema or tool name. This is highly efficient.

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

Completeness4/5

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

For a simple one-parameter read tool with no output schema, the description is largely complete: it states the operation, the target (homepage), the exact signals reported, and the access requirements. It could go slightly further by describing the output format or edge cases, but the enumeration of signals makes the expected return clear enough for an agent to invoke the tool correctly.

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 coverage for the only parameter is 100%: the 'url' field already includes a description with examples. The tool description adds the notion of reading the 'homepage', which slightly clarifies the parameter's semantic scope. Since the schema carries the parameter meaning, the description only needs minimal contribution, so the baseline 3 applies.

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 ('Read') and names the exact resource ('a site's homepage') with a concrete list of signals reported (title, description, canonical, hreflang, JSON-LD Schema.org types). This is clearly distinguishable from sibling tools like check_ai_access and check_identity_files, making the tool's purpose immediately clear.

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?

The description conveys a clear usage context: analyzing on-page SEO/structured-data signals from a homepage. The note 'Runs locally, no account needed' is a practical guideline, and the sibling tool names further clarify when this tool fits. However, it does not explicitly state when this tool should be avoided or name an alternative, so it falls just short of a 5.

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.

3 tool updatesv1.1.2Sep 8, 2026
- First observedcheck_ai_access
- First observedcheck_identity_files
- First observedcheck_page_signals

Deploy Server

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

TDQS

A4.2/5.0

Scored 2026-09-08 18:25 across 3 tools

Disambiguation5/5

Each tool targets a distinct aspect of site visibility: AI crawler access, identity files, and page signals. There is no functional overlap, so an agent can reliably select the right tool.

Naming Consistency5/5

All tools follow the same check_<object> pattern, making the set highly predictable. Naming is uniform and reflects a clear verb-noun convention.

Tool Count5/5

Three tools is a tight, focused set for a site analysis server. Each tool covers a distinct checking task and none feel redundant or out of scope.

Completeness4/5

The tools cover the main signals for AI visibility: robots.txt, identity files, and homepage metadata. A minor gap is the lack of a combined summary or deeper content analysis, but the core read-only audit workflow is well covered.

Maintenance

ActivityMaintained

ResponsivenessNo issues

Resources

Need Help?

Related Servers

Related MCP Connectors

alice
io.tranx
Audit any site's AI visibility from your assistant: crawler access, rendering, and schema.
1
seegeo
com.see-geo
Audit any website for AI visibility: graded report, findings with fixes, AI crawler access check.
Web Scraping Browser Automation Marketing
1
AEO Audit B
no.synligdigital
AEO audit: score any website 0-100 for AI visibility. Checks schema, meta, content, AI crawlers.
Web Scraping Search Marketing
42
Ninar AI A
ai.ninar
Audit your brand's visibility across ChatGPT, Gemini, Claude, Perplexity + 6 more engines.
Monitoring Search Marketing
52

Related MCP Servers

geo-audit
Marketing Developer Tools Search
nycsav
A
license
Not graded
quality
C
maintenance
Evaluates any website's AI visibility with 15 checks across crawlability, structure, content, and connectivity, and provides actionable fixes.
Updated 3 months ago (2026-06-12 19:30 UTC)
7 npm
MIT
Accrue SEO
Browser Automation Marketing Testing & QA Tools
glivera
F
license
Not graded
quality
D
maintenance
Audits any website for SEO issues, providing scored health checks, schema validation, and performance analysis through AI assistants.
Updated 4 months ago (2026-05-22 13:41 UTC)
-
Website Auditor MCP
Search Marketing
SpikeyCoder
A
license
A
quality
A
maintenance
Provides AI-visibility scoring and site auditing capabilities for websites, enabling agents to check how sites appear in AI engines like ChatGPT and Perplexity, run full SEO/security audits, and monitor changes over time.
Updated 4 days ago (2026-09-18 17:22 UTC)
15
136 npm
MIT
ai-search-audit
Marketing Search Web Scraping
d08m
A
license
Not graded
quality
B
maintenance
Enables auditing AI search visibility: checks site readiness for AI crawlers and measures whether ChatGPT, Gemini, and Perplexity recommend your site, including verbatim answers and citation gap analysis.
Updated 2 months ago (2026-08-05 12:23 UTC)
89 npm
4
AGPL 3.0

INITE MCP — AI visibility, from inside your agent

Works before you sign in

Install

Tools

Commands

What this package is

Account and allowance

Environment

Namespace

A note on the command name

Development

Licence

Available Tools

Tool Schema Changelog

Maintenance

Resources

Related MCP Connectors

Related MCP Servers