mcp
Server Details
SitePulsar AEO audits: fetch FIND/READ/USE agent-readiness scores for any website.
- Status
- Healthy
- Last Tested
- Transport
- Streamable HTTP
- URL
Glama MCP Gateway
Connect through Glama MCP Gateway for full control over tool access and complete visibility into every call.
Full call logging
Every tool call is logged with complete inputs and outputs, so you can debug issues and audit what your agents are doing.
Tool access control
Enable or disable individual tools per connector, so you decide what your agents can and cannot do.
Managed credentials
Glama handles OAuth flows, token storage, and automatic rotation, so credentials never expire on your clients.
Usage analytics
See which tools your agents call, how often, and when, so you can understand usage patterns and catch anomalies.
Tool Definition Quality
Average 4.1/5 across 13 of 13 tools scored.
Tools are mostly distinct, with a cluster of audit retrieval tools (get_audit, get_audit_detail, get_audit_full, get_fixes) that serve different granularities but could cause initial confusion if descriptions are not carefully read. Other tools like probes and scans are clearly separated.
All tools follow a consistent verb_noun pattern in snake_case, such as check_agent_readiness, run_audit, scan_visibility. The naming is predictable and easy to understand.
13 tools are well-suited for the AEO auditing domain, covering readiness checks, full audits, result retrieval in multiple forms, probes, scans, and searches. The count feels neither too sparse nor excessive.
The tool set covers the entire AEO workflow: initial readiness check, audit execution, results retrieval at summary/detail/fixes levels, comparisons, probes for MCP/UCP, and specialized scans. No obvious gaps for the intended purpose.
Available Tools
13 toolscheck_agent_readinessCheck Agent ReadinessARead-onlyIdempotentInspect
Fast synchronous AEO / agent-readiness read of a single URL: robots and bot access, structured data (schema), and content structure. Returns immediate signals without running a full audit.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | Absolute URL to audit. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint, openWorldHint, and idempotentHint. The description adds behavioral details: synchronous execution, speed, and immediate signals. No contradictions with annotations; additional context is beneficial.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with two sentences, front-loading key attributes ('fast synchronous') and listing specific scan areas. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple schema, lack of output schema, and existing annotations, the description is sufficiently complete. It specifies what is checked (robots, bot access, structured data, content structure) and contrasts with a full audit.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 100% coverage with a single 'url' parameter described as 'Absolute URL to audit.' The description adds 'single URL' but does not enhance parameter meaning beyond the schema. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool performs a fast synchronous read for a single URL, covering robots, bot access, structured data, and content structure. It distinguishes itself from a full audit, which aligns with sibling tools like run_audit and get_audit.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage through phrases like 'fast synchronous' and 'without running a full audit,' indicating it is for quick checks. However, it does not explicitly state when not to use it or mention alternatives, though sibling context provides some differentiation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
compare_aeoCompare AEO Across URLsAInspect
Compare AEO posture across multiple URLs (e.g. a brand versus its competitors) on the same FIND/READ/USE pillar scale. Async: returns an audit_id to poll with get_audit. Spends credits only for freshly-audited URLs; recent audits are reused uncharged.
| Name | Required | Description | Default |
|---|---|---|---|
| urls | Yes | Absolute URLs to compare. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond annotations (which indicate a non-read-only, non-destructive, non-idempotent tool), the description adds key behaviors: async execution, polling via audit_id, and conditional credit spending. This adds substantial value.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, each informative and without redundancy. The description is front-loaded with the core purpose and efficiently packs async and credit details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with one parameter and no output schema, the description fully explains the tool's function, async nature, polling mechanism, and credit policy. No gaps remain.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already covers the only parameter (urls) with 100% description coverage. The description adds a usage example but no new parameter semantics, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'compare' and resource 'AEO posture' and mentions the pillar scale. It clearly distinguishes from sibling tools like get_audit, which retrieve single audits, making the tool's unique purpose evident.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides a clear example (brand vs competitors) and explains when to use it via async behavior and credit reuse. Though it doesn't explicitly state when not to use, the context is sufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_auditGet Audit SummaryARead-onlyIdempotentInspect
Fetch an audit's status and, when complete, a compact decision-ready SUMMARY: AEO score (overall + FIND/READ/USE), a short summary, the weakest pillar, headline takeaways, and the top fixes. Lead with this; call get_audit_detail only when you need the full per-section breakdown.
| Name | Required | Description | Default |
|---|---|---|---|
| audit_id | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, openWorldHint, and idempotentHint. The description adds that the tool returns status and, when complete, a detailed summary including AEO score, summary, weakest pillar, takeaways, and fixes. This goes beyond annotations by specifying the output structure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, no fluff. First sentence defines output, second provides usage guidance. Every part is valuable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With one obvious parameter, no output schema, and good annotations, the description fully covers what an agent needs to decide to use this tool and understand its output. It also references the sibling tool for completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0% with no parameter description, but the single parameter 'audit_id' is self-evident from the tool name and context. The description does not elaborate on the parameter, but its purpose is clear enough for an agent.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states it fetches an audit's status and a compact decision-ready summary with specific fields (AEO score, summary, weakest pillar, takeaways, fixes). It distinguishes from sibling tool get_audit_detail by noting when to use each.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly instructs to 'Lead with this' and 'call get_audit_detail only when you need the full per-section breakdown', providing explicit when-to-use and when-not-to-use guidance with a named alternative.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_audit_detailGet Audit DetailARead-onlyIdempotentInspect
Full structured per-section breakdown of a completed audit, on demand (only call after get_audit when you need depth): per-dimension FIND/READ/USE sub-scores, reputation across AI engines, competitor cluster (named for paid tiers), crawl/schema/robots findings, agentic-readiness + USE functional probes, and rendered-DOM analysis (paid). Typed, sanitized, size-capped (see truncated/dropped_sections). Composite *_score fields listed in experimental_fields may change methodology — do not hardcode thresholds. Also surfaces author/E-E-A-T, content freshness, images, hreflang, per-page per-bot access, Schema.org Action microformats, OpenAPI sub-metrics, Google Intelligence, product readability, site maturity, and a methodology block — each tagged with an availability state in the availability map (present | not_detected | not_run_free_tier | phase_c_disabled | probe_failed | truncated | not_measured_legacy). Wave C adds deterministic signals: homepage content quality (named quotes, stats-with-source, answer-shape) under crawl.content_signals; per-page video + per-locale schema in page_signals; OpenAPI per-operation coverage %, OAuth scopes, and MCP tool annotations in agentic_detail.use_probes; and self-disclosed trust claims (certifications, SLA/uptime, AI-content disclosure, verifiable-claims) under agentic_detail.trust_claims — each labeled "disclosed"/"mentioned" (never "verified") with an evidence URL and extraction-confidence. All carry an availability state in the availability map.
| Name | Required | Description | Default |
|---|---|---|---|
| audit_id | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond annotations (readOnlyHint, openWorldHint, idempotentHint), the description discloses size capping with truncated/dropped_sections, composite score methodology changes, and detailed availability states. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is verbose and packed into two lengthy paragraphs, mixing multiple concepts. It could be more structured with bullet points or shorter sentences for easier parsing.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given one parameter and no output schema, the description covers the return structure extensively, including many fields and availability states. Missing parameter details slightly reduce completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0% for the only parameter (audit_id), and the description does not explain its format or how to obtain it. The description relies on prior knowledge from get_audit but fails to add explicit semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it provides a 'full structured per-section breakdown of a completed audit' and specifies when to call it ('only call after get_audit when you need depth'). It distinguishes from siblings like get_audit and get_audit_full by emphasizing depth.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states 'only call after get_audit when you need depth', providing clear context. It does not explicitly mention when not to use or alternatives, but the sibling list and the 'when you need depth' phrasing implicitly guides usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_audit_fullGet Full Audit ReportARead-onlyIdempotentInspect
One call that returns a completed audit's SUMMARY, full per-section DETAIL, and deduplicated prioritized FIXES together — so you don't have to chain get_audit → get_audit_detail → get_fixes. Use expand to trim the payload ('summary' | 'detail' | 'fixes' | 'all'; default 'all'). Same ownership, tier gating, and sanitization as those tools. For an in-progress audit it returns the status so you can keep polling. The detail layer includes Wave-B surfaced sections (author/E-E-A-T, freshness, images, hreflang, per-bot access, Action microformats, OpenAPI sub-metrics, Google Intelligence, product readability, site maturity, methodology) and Wave-C deterministic signals (content quality, video/locale, USE sub-metrics, trust claims) each with an availability state.
| Name | Required | Description | Default |
|---|---|---|---|
| expand | No | Which sections to include; default 'all'. | |
| audit_id | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, openWorldHint, and idempotentHint. The description adds context about behavior for in-progress audits (returns status for polling) and lists the detailed sections included. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is informative but verbose, listing many section names. While front-loaded with the main value proposition, the list of sections could be summarized or moved to a details section. Probably adequate.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema exists, so the description explains the return payload (summary, detail, fixes) and adds behavior for in-progress audits and availability state. It covers enough context for an agent to understand the tool's output without additional schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 50% (only expand has a description). The description reinforces expand usage with enum values and default, but does not add meaning to audit_id beyond its name. Baseline 3 is appropriate given partial coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states that this tool returns a combined payload of summary, detail, and fixes, eliminating the need to chain three separate calls. It explicitly distinguishes itself from siblings by naming the chaining pattern.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description advises using this tool instead of chaining get_audit, get_audit_detail, and get_fixes. It explains the expand parameter for payload trimming. However, it does not provide explicit when-not-to-use guidance or mention alternatives beyond the chaining pattern.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_fixesGet Prioritized FixesARead-onlyIdempotentInspect
Return the prioritized, pillar-tagged (FIND / READ / USE) action plan for a completed audit, deduplicated across sources, with machine-actionable implementation steps included on fixes where available.
| Name | Required | Description | Default |
|---|---|---|---|
| audit_id | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations (readOnlyHint, openWorldHint, idempotentHint) already indicate safe, idempotent behavior. Description adds value by mentioning deduplication and inclusion of implementation steps where available, but does not disclose further traits like auth requirements or pagination.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence that front-loads key attributes: prioritized, pillar-tagged, deduplicated, machine-actionable steps. No extraneous words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple input schema (1 param) and no output schema, the description adequately conveys the return value (action plan with tags, deduplication, steps). However, the absence of output schema means the agent misses structural details of the response.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has one required string parameter (audit_id) with 0% description coverage. The description provides context ('for a completed audit'), partially compensating, but lacks details on format or how to obtain the ID.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states the tool returns a prioritized, pillar-tagged action plan for a completed audit, with deduplication and machine-actionable steps. Distinguishes from sibling tools like get_audit by specifying 'fixes' and 'action plan' context.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Implies use after a completed audit but does not explicitly compare with alternatives (e.g., get_audit, get_audit_detail) or state when not to use. Lacks explicit usage guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
probe_agent_discoveryProbe Agent Discovery SurfacesARead-onlyIdempotentInspect
Checks selected registries (official MCP registry, PyPI, GitHub) for packages/servers tied to a domain or brand. A discovery-surface check, not a visibility check. Result: { state, score, tier, hits[], tool_schema_version }.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | Absolute https URL of the target (any public domain). | |
| brand | No | Optional brand/company name; inferred from the domain when absent. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, openWorld, idempotent. Description adds no new behavioral details beyond purpose.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
One sentence plus result format. Concise and front-loaded with action and purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers action and result shape. Lacks explanation of result fields like tier/score, but sufficient for a simple check tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema covers both parameters fully. Description does not add additional constraints or format beyond schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states it checks registries for packages/servers tied to a domain/brand, distinguishing from visibility check. Specific verb and resource.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Describes as 'discovery-surface check, not a visibility check', giving context but not explicit alternatives or when-not-to-use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
probe_mcp_functionalProbe MCP Endpoint PostureARead-onlyIdempotentInspect
Discovers a site's advertised MCP endpoint (mcp.json / .well-known) and inspects its declared OAuth/transport posture (advertised, not guaranteed-working). Result: { handshake_ok, declared_endpoint, declared_tool_names[], score, tool_schema_version }.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | Absolute https URL of the target (any public domain). | |
| brand | No | Optional brand/company name; inferred from the domain when absent. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint, openWorldHint, idempotentHint. The description adds that the inspection is of declared posture (not guaranteed-working) and specifies the result format, providing context beyond the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences: first defines purpose, second outlines result structure. No wasted words, efficient and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema exists, so the description compensates by listing result fields. For a simple probe tool, it covers the essential return values. Errors or rate limits are not mentioned but are acceptable given the tool's scope.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with both url and brand described. The description adds minimal extra meaning (e.g., 'absolute https URL') but largely repeats schema info. Baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's action: discovering a site's MCP endpoint and inspecting its OAuth/transport posture. It specifies the discovery targets (mcp.json / .well-known) and the result structure, differentiating it from sibling probes like probe_agent_discovery.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a caveat ('advertised, not guaranteed-working') but does not explicitly state when to use this tool versus alternatives such as probe_agent_discovery or probe_ucp_readiness. It implies usage for MCP endpoint inspection but lacks when-not guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
probe_ucp_readinessProbe UCP Shopping ReadinessARead-onlyIdempotentInspect
Inspects /.well-known/ucp to report whether AI shopping agents can transact with the site (presence + advertised capabilities only). Result: { has_ucp_profile, capabilities[], score, tool_schema_version }.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | Absolute https URL of the target (any public domain). | |
| brand | No | Optional brand/company name; inferred from the domain when absent. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, openWorld, and idempotent hints. The description adds that the tool inspects a specific endpoint and returns a structured result, but does not disclose additional behavioral traits beyond what annotations cover.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, focused sentence that directly states the action and includes the result format. No unnecessary words; every part adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (2 params, no output schema), the description covers the main purpose and result shape. However, it omits details on what the 'score' represents and the possible capabilities, which could be clarified for full understanding.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides clear descriptions for both parameters (url and brand), and schema coverage is 100%. The description does not add any new parameter semantics beyond what the schema already states.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the verb 'inspects' and resource '/.well-known/ucp', specifies the purpose of reporting whether AI shopping agents can transact, and distinguishes from sibling probes by focusing on UCP readiness and advertised capabilities.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not explicitly state when to use this tool versus alternatives like probe_agent_discovery or check_agent_readiness. Usage context is implied by the specific focus on UCP, but no direct guidance is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
run_auditRun Full AEO AuditAInspect
Run a full AEO audit of a URL covering FIND, READ, and USE. Async: returns an audit_id to poll with get_audit. Accepts an optional target_keyword. Spends one audit credit per fresh run; a same-URL re-run within 24h reuses the cached audit, uncharged.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | Absolute URL to audit. | |
| target_keyword | No | Optional keyword to evaluate against; inferred when absent. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds significant behavioral context beyond annotations: async execution with audit_id, credit cost, caching policy (same-URL re-run within 24h is free). Annotations only show readOnlyHint=false, no contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three concise sentences. First sentence defines purpose. Second explains async behavior. Third covers optional parameter and caching/credit. Front-loaded and no redundant words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description covers return value (audit_id), credit cost, and caching. It lacks description of response format or error cases, but for an async tool this is sufficient. Sibling tools exist but description is self-contained.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description repeats schema info ('Accepts an optional target_keyword') but does not add new meaning beyond what the schema already provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Run a full AEO audit of a URL covering FIND, READ, and USE,' specifying the verb (run), resource (audit), and scope. It distinguishes from sibling tools like get_audit which is for polling, and other scan tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides context: async polling, optional keyword, credit cost, and caching. It implies when to use (full audit needed) but does not explicitly contrast with siblings like compare_aeo or scan_page. Still clear enough for an agent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
scan_product_pageScan Product Page ReadabilityARead-onlyIdempotentInspect
Deterministically scores one product page (schema, price, availability, image) 0–100 for shopping-agent readability. No LLM involved. Available on Pro+ plans. Result: { result: { readability_score, ... }, tool_schema_version }.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | Absolute https URL of the target (any public domain). | |
| brand | No | Optional brand/company name; inferred from the domain when absent. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, openWorldHint, and idempotentHint. The description adds that the tool is deterministic and involves no LLM, and hints at the result structure. This context goes beyond the annotations, though it does not cover failure modes or rate limits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences: the first explains the tool's core function with specific criteria; the second adds plan restriction and result format. Every sentence adds value without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite no output schema, the description gives a concrete result structure (readability_score, tool_schema_version). It covers purpose, plan restriction, and key behavioral traits. Minor omissions like full output fields or error handling prevent a 5.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with both parameters (url, brand) described in the schema. The description does not add new parameter-level meaning beyond what the schema provides, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool scores a product page 0–100 for readability, listing specific criteria (schema, price, availability, image). It also emphasizes deterministic, no-LLM behavior, distinguishing it from sibling tools like scan_visibility or search_companies.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description only mentions availability on Pro+ plans but provides no explicit guidance on when to use this tool versus alternatives (e.g., sibling tools like check_agent_readiness or scan_visibility). It lacks when-to-use, when-not-to-use, or comparative rationale.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
scan_visibilityScan AI VisibilityARead-onlyIdempotentInspect
Live AI-visibility scan for a brand: crawl + reputation sampled across AI engines, returning where that brand is mentioned (any public brand, not just your own). Pro+ (LLM cost). Result: { reputation[], tool_schema_version }.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | Absolute https URL of the target (any public domain). | |
| brand | No | Optional brand/company name; inferred from the domain when absent. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnly, openWorld, and idempotent hints. The description adds value by detailing the crawl and reputation sampling across AI engines, mentioning the cost implication ('Pro+'), and the result structure, enhancing understanding of behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the core action and scope, and each sentence adds meaningful information without waste.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of AI-engine scanning and the absence of an output schema, the description provides a sufficient overview of the result format. It could elaborate on 'reputation' details but is complete enough for basic usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with clear parameter descriptions. The description reinforces that the brand parameter is optional and inferred from the domain, adding practical value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states a specific verb ('scan') and resource ('AI visibility for a brand'), and distinguishes itself from siblings by noting it covers any public brand. It clearly defines the scope and action.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is for live AI-visibility scanning and mentions it's a Pro+ feature, but does not specify when to use it versus sibling tools like search_companies or check_agent_readiness, nor provides explicit context or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
search_companiesSearch AI-Recommended CompaniesARead-onlyIdempotentInspect
Samples the major AI engines for which companies they name for a query; returns a consensus shortlist (≤5). Use to see who agents recommend — not where a brand is mentioned (scan_visibility). Result: { companies[], tool_schema_version }.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | Natural-language search query (3–200 chars). |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint, openWorldHint, idempotentHint. The description adds behavioral specifics like sampling multiple AI engines, consensus, and a limit of 5 results, enhancing transparency beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences efficiently cover purpose, usage, and result format with no superfluous words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description fully covers the tool's behavior, result structure, and usage guidance with no gaps given the single parameter and rich annotations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so description doesn't need to add parameter details. While the description mentions natural-language query and character length, it doesn't significantly exceed what the schema already conveys.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states that the tool samples major AI engines to produce a consensus shortlist of companies for a query, distinguishing it from sibling tool scan_visibility.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Description explicitly contrasts when to use this tool versus scan_visibility (recommendations vs. brand mention), providing clear usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Claim this connector by publishing a /.well-known/glama.json file on your server's domain with the following structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"maintainers": [{ "email": "your-email@example.com" }]
}The email address must match the email associated with your Glama account. Once published, Glama will automatically detect and verify the file within a few minutes.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
Discussions
No comments yet. Be the first to start the discussion!