Skip to main content
Glama
mambalabsdev

mcp-gtm-suite

by mambalabsdev
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

Audit Agent Accessibility

audit_agent_accessibility
Idempotent

Check if AI agents can read a domain: returns 42 fields on llms.txt, robots.txt AI policy, structured data, and machine-readable endpoints.

Instructions

Give it a domain and it returns whether an AI agent can read that site, and what the site's policy says, as one flat row of 42 fields across five families: the llms.txt family including llms-full.txt and ai.txt, robots.txt AI crawler policy including the newer Content Signal directives, structured data presence and health across JSON-LD, microdata, Open Graph and canonical, render mode, and machine readable endpoint discovery covering sitemap, OpenAPI, well known files and feeds. Every field is a fact read off a fetch. No model is called at any point, so the same domain returns the same row today and next month unless the site actually changed. Twelve requests per domain, typically 2 to 4 seconds. Built for a technical SEO or growth engineer preparing a site for AI crawlers, or an agency selling that work and needing a before and after audit across a client list. Requires an APIFY_TOKEN and consumes Apify credits. Read only.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
checksNoRun only these checks. Omit for all of them. Narrowing narrows the work, and the score is rescaled over the checks selected.
domainYesOne company domain, for example vercel.com. Protocol and path are stripped.
skipCacheNoLeave as false to use the 7 day cache. Set to true to re-audit the domain from scratch. Default: "false".
max_charge_usdNoOptional spending cap for this call, in USD, passed to the actor as max_charge_usd. The run stops before any charge that would take it past this amount and keeps every row already charged. Leave empty to rely only on the maximum charge per run set on your Apify account.
check_endpointsNoProbes sitemap, OpenAPI, well known files and feeds. Adds 7 concurrent requests. Default: true.
check_structured_dataNoParses JSON-LD, microdata, Open Graph and canonical off the homepage. Costs no extra requests. Default: true.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv1.14.0
    • addedInput schema / properties / max_charge_usd
      Added value: +{
+  "description": "Optional spending cap for this call, in USD, passed to the actor as max_charge_usd. The run stops before any charge that would take it past this amount and keeps every row already charged. Leave empty to rely only on the maximum charge per run set on your Apify account.",
+  "minimum": 0,
+  "type": "number"
+}
  2. Addedv1.1.1

TDQS

A3.6/5.0
Behavior1/5

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

The description ends with 'Read only,' but the annotations declare readOnlyHint=false (a tool with side effects). This is a direct contradiction about the tool's safety profile, which is exactly the signal an agent relies on. Although the description otherwise discloses a lot (12 requests, 2-4s, no model, token and credit requirements, 7-day cache), the explicit read-only claim contradicts structured data and is capped at 1 per the rules.

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 core action and result, and nearly every clause adds value (determinism, timing, billing, cache). It is dense and somewhat run-on, but not padded.

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?

Despite having no output schema, the description fully characterizes the return (42 flat fields across five named families), resource costs, timing, determinism, caching and auth requirements. An agent has everything needed to call and interpret it.

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%, so every parameter (checks, domain, skipCache, max_charge_usd, check_endpoints, check_structured_data) is already documented in the schema. The description adds context about the output families but no extra parameter syntax or semantics, 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?

States a specific action (given a domain, return whether an AI agent can read the site and what the policy says) and enumerates the five output families. This is unmistakably distinct from the GTM/sales-intelligence siblings, so an agent can route to it without ambiguity.

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?

Names clear contexts and personas: a technical SEO/growth engineer preparing a site for AI crawlers, or an agency needing a before/after audit across a client list. There is no explicit when-not guidance, but no sibling competes for the same task, so this is adequate.

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