A
license-
qualityC
maintenancePay-per-call MCP server for WebberSites x402 Data API, offering 45 tools for AI agents: web scraping, document extraction, SEO audits, linting, crypto data, and more, with payment via USDC on Base.
52
MIT
SEO Tools
Server Details
5 pay-per-call SEO tools over MCP. Free discovery, tool calls settle in USDC on Base via x402.
- Status
- Unhealthy
- 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.
MCP client
Glama
MCP server
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.
100% free. Your data is private.
Tool Definition Quality
B3.4/5.0
Tool DescriptionsB
Average 3.7/5 across 7 of 7 tools scored. Lowest: 3/5.
Server CoherenceB
Disambiguation3/5
Most tools have distinct purposes, but 'ai-overview-tracker' and 'llm-brand-visibility' both involve tracking AI citations, and 'ai-answer-change-alert' also monitors answers, creating potential confusion. Descriptions help clarify differences, but overlap remains.
Naming Consistency2/5
Tool names use inconsistent separators (hyphens vs underscore) and varying verb styles ('check', 'track', 'auditor', 'pricing_info'). No clear pattern, making it harder to predict tool names.
Tool Count4/5
With 7 tools, the count is appropriate for a focused SEO server covering AI-related checks. It is not too many or too few, fitting the scope well.
Completeness4/5
The tool set covers key areas of AI-era SEO (crawler access, LLM citations, brand visibility, social previews). Minor gaps like competitor analysis beyond brand visibility exist, but the domain is well-covered overall.
Available Tools
7 toolsai-answer-change-alertAInspect
Ask an LLM the queries that matter to you, compare each answer against its stored baseline and get told what changed — the answer itself and which domains it now cites or stopped citing. One row per query x model. — $0.10/call, x402 (USDC on base).
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| lang | No | Answer language (e.g. en, ru, tr). | en |
| models | No | OpenRouter model IDs to check. Grounded options: `perplexity/sonar`, `openai/gpt-4o-mini:online`, `google/gemini-2.0-flash-001:online`. Every model you add multiplies the number of billed rows: rows = number of queries × number of models. With the limits on both fields, the maximum possible is 20 queries × 3 models = 60 rows. | |
| queries | Yes | The prompts a real user would ask (e.g. `best crm for small business`). Each query is run against every model in `models` below and compared against the previous run's stored answer for the same query × model × language — you are charged per query × model pair, not per query, whether or not the answer changed. | |
| maxConcurrency | No | Parallel LLM calls (kept low to respect rate limits and to bound how many LLM calls can be wasted — uncharged — if a run's spend limit is hit mid-run). | |
| openrouterApiKey | No | Your OpenRouter API key (https://openrouter.ai/keys). Optional: without it the built-in key is used and the LLM cost is covered by the per-row price. Pass your own key to have tokens billed to your account instead, at cost. |
Tool Definition Quality
A4.2/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses that the tool calls LLMs via OpenRouter, compares answers against a stored baseline, cites domains, charges $0.10/call, and has concurrency limits. It also explains billing per query×model pair. However, it does not clarify how long baselines are stored or whether runs are cumulative, which would be helpful for understanding persistence.
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 two sentences plus a pricing note, with no wasted words. The core functionality is front-loaded in the first sentence, and additional details (pricing, row calculation) are logically appended. Every sentence provides essential information.
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?
Given the absence of an output schema, the description explains what the tool returns ('the answer itself and which domains it now cites or stopped citing') and provides pricing and limitation details. This is sufficient for an agent to understand the tool's behavior, though the output format could be more explicitly described.
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 baseline is 3. The description adds significant value beyond the schema by explaining the billing implications of 'models' and 'queries', the purpose of 'maxConcurrency' (to respect rate limits and avoid waste), and the optionality and effect of 'openrouterApiKey'. This enhances the agent's understanding of parameter usage.
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 clearly states the tool's purpose: 'Ask an LLM the queries that matter to you, compare each answer against its stored baseline and get told what changed — the answer itself and which domains it now cites or stopped citing.' This is a specific verb ('compare', 'get told') and resource ('LLM answers with baselines'), and it clearly distinguishes from sibling tools like 'ai-crawler-access-checker' or 'llm-brand-visibility' which serve different functions.
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 usage for tracking changes in LLM answers over time, and mentions pricing and row calculation. However, it does not explicitly state when to use this tool versus alternatives (e.g., for single-shot queries or other monitoring tools), nor does it provide when-not-to-use guidance. The context is clear but incomplete.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
ai-crawler-access-checkerBInspect
Check which AI crawlers (GPTBot, ClaudeBot, PerplexityBot, Google-Extended & more) can access your website. Bulk audit of robots.txt rules, llms.txt presence and sitemap for AI search visibility (GEO/AEO). — $0.01/call, x402 (USDC on base).
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| websites | Yes | List of website URLs or domains to audit (e.g. `example.com` or `https://example.com`). | |
| maxConcurrency | No | How many websites to check in parallel. |
Tool Definition Quality
B3.4/5.0
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits. It mentions pricing and network (x402) but does not discuss side effects, rate limits, authentication, or what happens during the audit. For a tool that likely makes network requests, this is insufficient.
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?
The description is concise at two sentences, front-loading the core purpose. It includes specific crawlers and audit details. Minor marketing fluff (GEO/AEO, pricing) does not detract significantly, but a tighter focus would improve scoring.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the moderate complexity (2 params, no output schema), the description covers what is checked but omits output format or interpretation of results. It also introduces acronyms without explanation (GEO/AEO). A higher score would require more on expected return behavior.
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% (both parameters have descriptions). The tool description adds minimal parameter-level meaning beyond the schema, such as the term 'bulk audit' relating to the websites array. The baseline of 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 clearly states the tool's function: checking which AI crawlers can access a website. It lists specific crawlers (GPTBot, ClaudeBot, PerplexityBot, Google-Extended) and mentions the audit scope (robots.txt, llms.txt, sitemap). This is specific and distinguishes it from sibling tools like llms-txt-auditor.
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 the tool is for auditing AI crawler access but does not provide explicit guidance on when to use it versus alternatives. It mentions bulk auditing but lacks context on prerequisites or exclusions. A higher score would require explicit use-case scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
ai-overview-trackerBInspect
For each query that matters, see which sources and domains AI assistants cite in their answer — grounded via Perplexity Sonar, GPT or Gemini through your own OpenRouter key. GEO citation tracking: the backlink profile of the AI-answer era. — $0.10/call, x402 (USDC on base).
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| lang | No | Answer language (e.g. en, ru, tr). | en |
| models | No | OpenRouter model IDs to test. Grounded options: `perplexity/sonar`, `openai/gpt-4o-mini:online`, `google/gemini-2.0-flash-001:online`. Every model you add here multiplies the number of billed rows: rows = number of queries × number of models (see `queries`). | |
| queries | Yes | The prompts a real user would ask (e.g. `best project management software`, `how to choose a CRM`). Each query is run against EVERY model in `models` below, and you are charged per query × model pair, not per query — e.g. 10 queries × 2 models = 20 billed rows. With the limits on both fields, the maximum possible is 20 queries × 5 models = 100 rows. | |
| maxConcurrency | No | Parallel LLM calls (kept low to respect rate limits). | |
| openrouterApiKey | No | Your OpenRouter API key (https://openrouter.ai/keys). LLM token cost is billed to YOUR account; this Actor only orchestrates and scores. Optional to start the Actor: without it the run finishes cleanly and explains setup, and nothing is charged beyond the Actor start. |
Tool Definition Quality
B3/5.0
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden but only reveals the basic function and required OpenRouter key. It omits side effects, output structure, rate limits, or what happens without the API key (only noted in parameter description). The promotional language ('GEO citation tracking', 'backlink profile of the AI-answer era') adds no behavioral insight.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is brief (two sentences plus pricing) but includes promotional fluff ('For each query that matters', 'backlink profile of the AI-answer era'). It is not maximally concise; the essential functional statement is clear but could be tighter without marketing phrases.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has 5 parameters and no output schema, yet the description fails to explain the output format (e.g., how citations are presented, what data fields are returned). It also omits details about the 'x402' and 'USDC on base' references, leaving significant gaps for an agent to understand the tool's full behavior.
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 parameters are already well-documented. The description adds marginal value by mentioning 'GEO citation tracking' and models, but this aligns with schema descriptions. Baseline 3 is appropriate as the description does not introduce new semantic depth beyond 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?
The description clearly states the tool's function: 'see which sources and domains AI assistants cite in their answer'. It specifies the verb (see) and the resource (citations from AI overviews), and distinguishes it from siblings like 'llm-brand-visibility' by focusing on citation sources and domains.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives or when not to use it. It mentions pricing but does not contrast with sibling tools or specify appropriate use cases, leaving the agent without decision-making context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
llm-brand-visibilityAInspect
For each query that matters, check whether AI assistants recommend YOUR brand — and which competitors they cite instead. Grounded answers from Perplexity Sonar, GPT and Gemini via your own OpenRouter key. This is GEO: the SEO of the AI era. — $0.10/call, x402 (USDC on base).
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| lang | No | Answer language (e.g. en, ru, tr). | en |
| brand | Yes | The brand, product or company you want to track in AI answers. | |
| models | No | OpenRouter model IDs to test. Grounded options: `perplexity/sonar`, `openai/gpt-4o-mini:online`, `google/gemini-2.0-flash-001:online`. Every model you add here multiplies the number of billed rows: rows = number of queries × number of models (see `queries`). | |
| queries | Yes | The prompts a real user would ask (e.g. `best note-taking app`, `Notion alternatives`). Each query is run against EVERY model in `models` below, and you are charged per query × model pair, not per query — e.g. 10 queries × 2 models = 20 billed rows. With the limits on both fields, the maximum possible is 20 queries × 5 models = 100 rows. | |
| maxConcurrency | No | Parallel LLM calls (kept low to respect rate limits). | |
| openrouterApiKey | No | Your OpenRouter API key (https://openrouter.ai/keys). LLM token cost is billed to YOUR account; this Actor only orchestrates and scores. Optional to start the Actor: without it the run finishes cleanly and explains setup, and nothing is charged beyond the Actor start. |
Tool Definition Quality
A3.5/5.0
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses that the tool uses an external API key (OpenRouter), costs $0.10 per call, and that rows billed equal number of queries times number of models. However, it does not mention side effects, idempotency, or what happens on error (e.g., invalid key). The concurrency parameter is described as being kept low for 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is relatively concise and front-loads the core purpose. However, it includes marketing language ('This is GEO: the SEO of the AI era.') and pricing details that could be considered extraneous. Still, it efficiently conveys the tool's function and key constraints.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has no output schema and no annotations, so the description should cover what the tool returns and how to interpret results. The description only explains the input and pricing, not the output format or error behavior. This is a significant gap for a tool that performs external API calls and returns data.
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 provides detailed descriptions for all 6 parameters (100% coverage). The tool's description adds overall context about the pricing model and the relationship between 'queries' and 'models' (rows = queries × models), which the schema also explains. Since the schema does the heavy lifting, the description adds marginal value, earning a baseline score of 3.
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 clearly states the tool's purpose: to check whether AI assistants recommend a specific brand and cite competitors for given queries. It specifies the resources (Perplexity Sonar, GPT, Gemini) and distinguishes from sibling tools like 'ai-crawler-access-checker' and 'ai-overview-tracker', which address different AI-related use cases.
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?
Usage is implied through the description (e.g., 'For each query that matters, check whether AI assistants recommend YOUR brand'), but there is no explicit guidance on when to use this tool versus alternatives, nor when not to use it. The pricing and model details provide some context, but no direct comparison to sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
llms-txt-auditorAInspect
Give it a domain. It checks whether the site publishes a valid llms.txt / llms-full.txt (the emerging AI-crawler-friendly-docs convention) and whether robots.txt blocks GPTBot, ClaudeBot, Google-Extended, PerplexityBot and 5 other AI crawlers. llms.txt-first, no browser, no LLM, no API key. — $0.01/call, x402 (USDC on base).
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| items | Yes | List of domains to audit for llms.txt presence and AI-crawler robots.txt policy. | |
| maxConcurrency | No | How many domains to audit in parallel. |
Tool Definition Quality
A4.1/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, but the description discloses key behaviors: it checks both llms.txt and robots.txt, is a paid tool ($0.01/call), and doesn't use browser/LLM/API key. This is sufficient for understanding its safety and cost profile.
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?
The description is a single paragraph that is concise and front-loaded with the action. It includes pricing and payment info which, while useful, could be separated. No wasted words.
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?
Given the tool's moderate complexity (two checks) and no output schema, the description provides sufficient context: what it does, payment method, and limitations (no browser/LLM). Missing details on return format or error handling, but acceptable.
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?
Input schema covers 100% of parameters with descriptions for 'items' and 'maxConcurrency'. The tool description does not add additional meaning beyond what the schema provides, leading to a baseline score of 3.
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 clearly states the tool checks for valid llms.txt/llms-full.txt and robots.txt blocking of specific AI crawlers, with a specific verb 'checks' and resource 'domain'. This distinguishes it from sibling tools like 'ai-crawler-access-checker' which likely focuses only on robots.txt.
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?
Description mentions it is 'llms.txt-first, no browser, no LLM, no API key' and pricing, suggesting usage context. However, it does not explicitly state when not to use it or compare to alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
pricing_infoAInspect
Free — list every paid tool in the 'seo-tools' bundle with its price, payTo address and network. Call this first if you don't have a wallet ready yet.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Tool Definition Quality
A4.5/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. It mentions 'Free' and lists the output, implying a safe, read-only query. It does not disclose any side effects, but none are expected for a listing tool.
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, front-loaded sentence with no wasted words, effectively conveying purpose and usage guidance.
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?
Given no output schema, the description fully explains what is returned (tools with price, address, network) and provides a usage hint, making it complete for a parameterless tool.
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?
No parameters exist, and schema coverage is 100%. The description does not need to add parameter info; baseline 4 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 clearly states the tool lists paid tools in the 'seo-tools' bundle with price, payTo address, and network. It distinguishes from sibling tools which are other SEO analysis tools, and provides a 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.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says 'Call this first if you don't have a wallet ready yet', providing a clear usage scenario. It doesn't specify when not to use, but the context is sufficient for the agent.
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!
Related MCP Servers
- Alicense-qualityCmaintenanceExposes professional SEO tools (content briefs, keyword research, SERP analysis, backlink profiles, and on-page audits) to MCP-compatible AI agents with automatic x402 micropayment handling on Base.61MIT
- Alicense-qualityBmaintenanceMCP server exposing 10 curated tools for AI agents, providing crypto trading signals, on-chain analysis, and web utilities via pay-per-call x402 endpoints on the Base network.MIT
- Alicense-qualityCmaintenanceMCP server that provides AI agents with pay-per-call access to a suite of tools (honeypot check, token market, DeFi yields, etc.) via USDC on Base using the x402 protocol.23MIT
social-preview-checkerBInspectSee exactly how your links look when shared on Telegram, WhatsApp, X, LinkedIn, Slack, Facebook & Discord. Bulk-audit Open Graph and Twitter Card tags, validate preview images, and find what breaks your link previews. — $0.01/call, x402 (USDC on base).
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description must fully disclose behavior. It mentions pricing and a numeric limit ('x402') without explanation, and fails to describe failure modes, rate limits, or authorization requirements. The tool is likely read-only but is not explicitly stated.
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 convey the primary function and cost. Front-loaded with the core purpose. Minor: pricing detail could be separate, but it does not cause confusion.
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 lacks critical details about output format, error handling, or what exactly is returned. For a paid tool, agents need to know the response structure to interpret results and handle errors.
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%, so baseline is 3. The description adds context about social preview validation but does not clarify parameter formats beyond what the schema already provides (e.g., URL format, concurrency bounds).
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 checks link previews across multiple social platforms, validates Open Graph and Twitter Card tags, and identifies issues. It distinguishes itself from sibling tools like 'ai-crawler-access-checker' and 'llm-brand-visibility' by focusing specifically on social preview debugging.
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 for debugging social link previews but does not explicitly state when to use this tool versus alternatives or any exclusion criteria. The pricing hint ($0.01/call) suggests cost sensitivity but no guidance on when to avoid.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.