8 pay-per-call web intelligence tools for AI agents: detect a site's tech stack and track stack changes, check domain health, extract structured data or clean markdown from any URL, turn sitemaps into knowledge bases, analyze Shopify and Zid stores. Free discovery + pricing_info; paid calls $0.01-0.02 in USDC on Base via x402 — pay only for successful runs.
Bulk-audit domains: DNS records, SSL certificate expiry, SPF & DMARC email authentication. Find domains that cannot receive email, are easy to spoof, or have expiring certificates — before your clients do. — $0.01/call, x402 (USDC on base).
| Name | Required | Description | Default |
|---|---|---|---|
| domains | Yes | List of domains to audit (e.g. `example.com`). | |
| maxConcurrency | No | How many domains to check in parallel. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, covering the safety profile. The description adds meaningful behavioral context beyond that: it specifies what the tool checks (DNS, SSL, SPF/DMARC), what it finds (cannot receive email, spoofable, expiring certs), and introduces a cost element ($0.01/call, x402/USDC) not visible in annotations or schema. This is more transparency than the baseline but stops short of discussing response format or potential external dependencies.
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 and front-loads the action: 'Bulk-audit domains' followed by specifics. Every clause carries information: checks performed, outcome use case, and cost. No fluff, no repetition of schema or title. It is concise and well-structured.
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 moderate complexity and absence of an output schema, the description sufficiently conveys the primary use cases and expected findings (email reception, spoofing risk, certificate expiry). It also includes cost, which is relevant for an agent deciding to invoke it. It does not describe the exact output structure, but the core context is complete enough for an agent to select the tool correctly. Slightly more detail about result format would be needed for 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 description coverage is 100%, with both parameters ('domains' and 'maxConcurrency') already well-documented. The description does not add extra parameter syntax, format details, or examples beyond what the schema provides. It only loosely reinforces the 'domains' parameter by saying 'Bulk-audit domains.' Thus, the description adds no additional semantic value beyond the schema, meeting the baseline of 3.
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 'bulk-audit' and names the resource (domains) with concrete checks (DNS records, SSL expiry, SPF/DMARC). It clearly distinguishes itself from sibling tools by explaining its unique value proposition: finding domains that cannot receive email, are easy to spoof, or have expiring certificates. This is far beyond a vague purpose.
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 when to use this tool: when auditing domains for email deliverability, spoofing risk, or certificate expiry, especially in a client-facing context ('before your clients do'). It does not explicitly mention alternatives or state 'when not to use,' but the use case is clear and distinct from the sibling context (e.g., Shopify monitoring, URL extraction). This is strong implied guidance but lacks explicit exclusion.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Free — list every paid tool in the 'web-intel' bundle with its price, payTo address and network. Call this first if you don't have a wallet ready yet.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate read-only and non-destructive. The description adds that it is free and discloses the return content (price, payTo address, network), which is useful context beyond what annotations provide.
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 with no redundancy: first states the function and output, second gives a clear usage directive. Every word earns its place.
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 tool with no parameters and no output schema, the description is complete: it names the bundle, the specific fields returned, and the free nature. It doesn't explicitly define the return type, but 'list every' implies an array, which is sufficient for selection.
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?
With 0 parameters and 100% schema coverage, the description need not explain parameters. Baseline for 0 params is 4, and the description correctly implies no input is required.
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 lists every paid tool in the 'web-intel' bundle with price, payTo address, and network. The verb 'list' and specific resource distinguish it from sibling tools like shopify monitors or tech-stack detectors.
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 explicit usage guidance: 'Call this first if you don't have a wallet ready yet.' This tells the agent when to invoke it, though it doesn't mention alternatives or 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.
Watches a Shopify store's catalogue and returns only the products whose price or availability changed since the previous check. The first run creates the baseline and says so. — $0.05/call, x402 (USDC on base).
| Name | Required | Description | Default |
|---|---|---|---|
| websites | Yes | Shopify (or possibly-Shopify) store URLs to watch, e.g. "allbirds.com". Every scheduled run re-checks these same sites and reports ONLY what changed since a previous run of this watch: a store newly added to the watch, or an already-tracked store's price range / catalog size / estimated revenue band shifting. | |
| max_items | No | Caps how many new-store / changed-store rows a single run will deliver and charge for, even if more were found. | |
| baseline_key | No | A name for THIS watch, so you can run several independent store watches from one Actor (e.g. "dtc-competitors", "my-portfolio") without one overwriting another's memory of what's already been seen. Each name is scoped to YOUR OWN Apify account. The prefilled value is only there so this Actor's own daily test run has a stable, obviously-a-test name; replace it with your own watch name. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations include readOnlyHint=false, idempotentHint=false, and destructiveHint=false, but the description adds valuable context: it maintains a stateful baseline (first run creates baseline and says so) and costs $0.05 per call. This goes beyond the annotations without contradicting them, though it does not detail auth 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?
The description is a single, front-loaded sentence stating exactly what the tool does, followed by a brief pricing note. No wasted words; it is immediately scannable and actionable.
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 clarity on the output granularity: it says 'products' but the websites parameter description mentions 'store newly added' and 'price range / catalog size / estimated revenue band shifting,' suggesting store-level aggregates. With no output schema, this ambiguity is critical. The description also does not explain what a returned change row looks like, making it incomplete for an agent to confidently invoke the 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 coverage is 100%, with detailed descriptions for all three parameters. The main description does not add parameter-specific semantics beyond what the schema already provides; the baseline_key description in the schema gives extra context about scoping, so the 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 it watches a Shopify store's catalogue and returns only products whose price or availability changed since the previous check. This distinguishes it from siblings like shopify-store-intelligence (general intelligence) and tech-stack-change-detector (tech stack focus). The baseline creation behavior is also noted.
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 use for monitoring price/availability changes over time ('since the previous check', 'first run creates baseline'), but it does not explicitly state when to prefer this over alternatives or provide exclusion criteria. The parameter description adds context about scheduled runs, but the main text lacks 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.
Confirm a site runs on Shopify and pull store intelligence from its public feeds — product count, price range, top vendors/categories, newest listing and a rough revenue-band heuristic. No login, no Shopify API key. — $0.01/call, x402 (USDC on base).
| Name | Required | Description | Default |
|---|---|---|---|
| websites | Yes | List of websites to check (e.g. `allbirds.com` or `https://example.com`). One row per site. | |
| maxConcurrency | No | How many websites to check in parallel. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint=true and destructiveHint=false. The description adds valuable non-obvious behavior: per-call cost ($0.01/call), no auth needed, reliance on public feeds, and the heuristic nature of the revenue-band estimation. It does not disclose behavior for non-Shopify or invalid sites, but the gap is small given annotation coverage.
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, dense sentence that front-loads the purpose and immediately lists specific outputs, followed by crucial pricing/auth details. No word is wasted; the cost and no-key info are presented as a secondary clause without bloat.
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 lacking an output schema, the description enumerates the return fields (product count, price range, etc.). It covers cost, auth, and read-only nature. Missing edge-case details (e.g., handling of non-Shopify sites) and explicit concurrency behavior, but these are minor for a simple read-only tool with good 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 description coverage is 100% for both parameters (websites and maxConcurrency), including formats and defaults. The description adds no parameter-specific context beyond the schema, so a baseline 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 function: confirm Shopify usage and pull store intelligence (product count, price range, vendors, etc.). It uses specific verbs ('confirm', 'pull') and a specific resource ('public feeds'), distinguishing it from siblings like the general tech-stack-detector.
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?
Provides clear context: it is for Shopify sites, uses public feeds, requires no login/API key, and costs money. It does not explicitly name alternatives or exclusions (e.g., 'for general stack detection, use tech-stack-detector'), but the Shopify-specific scope and output list imply when to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Give it a domain. It reads the sitemap, fetches the pages, strips them to clean text and splits everything into ~1000-char chunks — one dataset row per chunk, ready to embed into a vector store. No browser, no LLM, no API key. — $0.02/call, x402 (USDC on base).
| Name | Required | Description | Default |
|---|---|---|---|
| items | Yes | List of domains or website URLs to crawl via their sitemap. One entry per site. | |
| maxConcurrency | No | How many SITES to process in parallel (each site already fetches up to 25 pages internally). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the annotations (readOnly, non-destructive), the description discloses the entire processing pipeline, cost per call ($0.02), payment method (x402/USDC), and constraints like 'no browser, no LLM, no API key'. This adds significant behavioral context and is fully consistent 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 a compact, front-loaded paragraph. Every sentence earns its place—process explanation, constraints, cost, and payment. No fluff, and it fits the tool's actual complexity.
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 tool is simple, and the description covers the full workflow, output format ('one dataset row per chunk'), constraints, and cost. Despite no output schema, the description compensates by describing what the result looks like, making it complete for an agent to invoke correctly.
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 the parameters are already well-documented. The description adds minimal extra meaning beyond 'Give it a domain' for the items parameter, but the schema already explains both items and maxConcurrency. 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 a specific verb chain ('reads the sitemap, fetches the pages, strips them to clean text and splits everything into ~1000-char chunks') and clearly identifies the resource (domains) and purpose (RAG dataset building). It distinguishes itself from siblings like url-to-markdown by focusing on whole-site sitemap crawling and chunked output.
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 implies usage for building vector-store-ready datasets from a website's sitemap. It mentions what the tool does not require (browser, LLM, API key), which helps set expectations, but it does not explicitly name alternative tools or state when not to use it. Still, the context is strong enough.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Turn any URL into clean structured JSON — title, description, image, JSON-LD, headings, links, emails and prices — extracted deterministically via regex. Zero LLM calls, zero API keys. Built for AI agents that need one page turned into typed data, cheaply. — $0.01/call, x402 (USDC on base).
| Name | Required | Description | Default |
|---|---|---|---|
| urls | Yes | List of URLs to extract structured data from. One row per URL. | |
| fields | No | Optional subset of fields to return: title, description, image, siteName, canonical, jsonLd, headings, links, emails, prices. Leave empty to extract all of them. | |
| maxConcurrency | No | How many URLs to process in parallel. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover read-only and non-destructive behavior. The description adds valuable behavioral context: extraction is deterministic via regex, involves zero LLM calls and zero API keys, and has a known cost ($0.01/call, x402 USDC). This goes beyond the annotations and helps the agent anticipate operational characteristics.
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 front-loaded with the main purpose, followed by method, target audience, and pricing. It's about 70 words and every segment adds context. The pricing and audience details, while useful, extend it slightly beyond the crispest possible form, so a 4 is appropriate.
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 explains the return format ('structured JSON') and enumerates the fields, which is sufficient for output understanding. It also covers use cases, cost, and method. It doesn't address potential failures or edge cases, but for a deterministic extractor with robust schema, this is a minor gap—hence a 4.
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 the parameters are fully documented there. The description adds minimal parameter-specific meaning beyond what the schema provides—it lists the extractable fields in prose, which reinforces the 'fields' parameter but doesn't introduce new semantics. This matches the baseline for high 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 uses a specific verb ('Turn') with a clear resource ('any URL') and outcome ('into clean structured JSON'), listing the exact data points extracted (title, description, image, JSON-LD, headings, links, emails, prices). It distinguishes from siblings like url-to-markdown by explicitly emphasizing structured JSON and deterministic extraction via regex.
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 contextualizes when to use: 'Built for AI agents that need one page turned into typed data, cheaply.' It also notes zero LLM calls/API keys, implying a use case where deterministic, low-cost extraction is preferred. However, it doesn't explicitly name alternatives or when-not-to-use scenarios, so it's one point short of a perfect 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Detect a website's current technologies (CMS, ecommerce, analytics, marketing/CRM, framework, hosting/CDN, chat, payments) and diff it against a previously-seen stack you supply, so you get exactly what was added or removed. No browser, no proxies, no login. — $0.01/call, x402 (USDC on base).
| Name | Required | Description | Default |
|---|---|---|---|
| items | Yes | One entry per domain. Bare form: "example.com" (just detects the current stack). Diff form: "example.com|Tech1,Tech2,Tech3" — everything after the pipe is the stack you last saw for this domain; the Actor returns what was added/removed vs. right now. | |
| maxConcurrency | No | How many domains to check in parallel. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=true. The description adds meaningful context: 'No browser, no proxies, no login' and pricing ($0.01/call, x402). These details go beyond annotations and set expectations for execution environment and cost, without contradicting the read-only nature.
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, information-dense sentence that front-loads the core functionality and includes a brief pricing note. No filler or redundancy; every word contributes to understanding what the tool does and its constraints.
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 tool with 2 params and no output schema, the description adequately covers the main use case, diff input format (mentioning 'previously-seen stack'), and key operational traits (no browser/proxies). It doesn't describe the output structure, but the phrase 'exactly what was added or removed' gives enough of a picture for simple 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 description coverage is 100%, and the schema itself explains the 'items' format (bare or diff form) and 'maxConcurrency'. The description adds no new parameter syntax beyond what the schema provides, so the 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's function: 'Detect a website's current technologies ... and diff it against a previously-seen stack you supply, so you get exactly what was added or removed.' This uses a specific verb (detect and diff) and resource (website stack), and distinguishes from the sibling 'tech-stack-detector' by emphasizing the comparison against a supplied baseline.
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 phrase 'previously-seen stack you supply' clearly indicates this tool is for change detection when a prior stack is known, implicitly differentiating from simpler detection tools. It does not explicitly name alternatives or state 'when not to use', but the context is strong and the pricing note adds practical guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Detect the technologies a website runs — CMS, ecommerce platform, analytics, marketing/CRM, JS framework, hosting/CDN, chat and payments — straight from its public HTML and HTTP headers. No browser, no proxies, no login. Built for sales targeting and competitive research. — $0.01/call, x402 (USDC on base).
| Name | Required | Description | Default |
|---|---|---|---|
| websites | Yes | List of websites to fingerprint (e.g. `shopify.com` or `https://example.com`). One row per site. | |
| maxConcurrency | No | How many websites to fingerprint in parallel. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate read-only and non-destructive behavior. The description adds valuable context: the method (public HTML and HTTP headers), no login requirement, and the exact cost per call ($0.01). This goes beyond the minimal annotation disclosure and does not contradict it.
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 deliver the full purpose, detection categories, technical method, use case, and pricing. Every phrase is purposeful, with no filler or 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?
For a 2-parameter tool with no output schema, the description sufficiently conveys what is detected, how it works, and why you'd use it. It stops short of describing the output format, but for this simple detection task, the implied response (list of detected technologies) is reasonable.
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 already provides 100% coverage of both parameters (websites list and max concurrency) with descriptions. The tool description adds no parameter-specific meaning, 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 uses the specific verb 'Detect' and clearly defines the resource: technologies a website runs, enumerating categories (CMS, ecommerce, analytics, etc.). It naturally distinguishes from the sibling tool 'tech-stack-change-detector' by focusing on current stack rather than changes.
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 states the intended use ('Built for sales targeting and competitive research') and key constraints ('No browser, no proxies, no login'). However, it doesn't explicitly mention when to use an alternative like tech-stack-change-detector for change tracking, so guidance is strong but not fully exclusive.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fetch any URL and convert it into clean, LLM-ready Markdown — headings, links, lists and emphasis preserved, scripts/nav/ads stripped. No browser, no LLM calls, no API key. Built for RAG pipelines and AI agents that need one page turned into readable text, cheaply. — $0.01/call, x402 (USDC on base).
| Name | Required | Description | Default |
|---|---|---|---|
| urls | Yes | List of URLs to fetch and convert to Markdown. One row per URL. | |
| includeLinks | No | Convert <a href> tags to Markdown links. Turn off to strip links and keep only their text. | |
| maxConcurrency | No | How many URLs to fetch and convert in parallel. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, openWorldHint=true, and destructiveHint=false, covering the safety profile. The description adds valuable behavioral context beyond annotations: it strips scripts/nav/ads, requires no browser or LLM calls, and costs $0.01/call. These details are not redundant with annotations and help the agent understand side effects and constraints.
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 and well-structured. The first sentence captures the core function, followed by practical details (cost, dependencies, use case). No filler or redundancy; the pricing and target audience are stated succinctly.
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 tool with 3 parameters (1 required), no output schema, and robust annotations, the description is largely complete. It explains the output concept ('LLM-ready Markdown') and key behavioral facts (stripping, cost, no dependencies). However, it does not explicitly describe how the markdown is returned (e.g., as a string or structured object), nor how errors or multiple URLs are handled, leaving minor gaps.
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 the baseline is 3. The description does not add extra meaning about the parameters themselves; it only mentions 'headings, links, lists and emphasis preserved' which loosely relates to includeLinks but doesn't explain the parameter semantics beyond what the schema already provides. Since the schema fully documents each parameter, no additional credit is warranted.
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 function with a specific verb and resource: 'Fetch any URL and convert it into clean, LLM-ready Markdown'. It distinguishes from siblings by detailing what is preserved (headings, links, lists, emphasis) and what is stripped (scripts/nav/ads), making it unique among the listed 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 clear context for when to use the tool: 'Built for RAG pipelines and AI agents that need one page turned into readable text, cheaply.' It does not explicitly state exclusions or alternatives, but the use case is well-defined and differentiates from sibling tools. The mention of no browser/LLM/API key also helps the agent decide if it fits.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Pull live product catalogs (name, price, sale price, category, image) straight from Zid storefronts — a common Saudi/Gulf e-commerce SaaS — via their own public JSON feed. No login, no browser, no proxies. — $0.02/call, x402 (USDC on base).
| Name | Required | Description | Default |
|---|---|---|---|
| items | Yes | One entry per Zid storefront — the shop's subdomain (e.g. `furniture`) or full host (`furniture.zid.store`). Find the subdomain in the store's own zid.store URL, or via its custom domain's storefront (Zid stores usually keep the *.zid.store host reachable even with a custom domain attached). | |
| maxConcurrency | No | How many shops to scan in parallel. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, openWorldHint=true, and destructiveHint=false. The description adds valuable behavioral context: it accesses a public JSON feed, requires no authentication or proxies, and costs $0.02/call with USDC on Base. This goes beyond the annotations and gives the agent a clear picture of network and billing implications.
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 concise sentences. The first sentence front-loads the core function and output fields, while the second adds access method and pricing. Every clause earns its place, with no redundant or filler content.
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 completely explains outputs (fields returned) and access constraints (public feed, no login/proxies). Combined with thorough schema and annotations, this covers the essential usage context for a simple scraping tool. It omits edge-case behaviors like rate limiting or error handling, but these are not critical given the tool's simplicity and annotation coverage.
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 100% coverage of both parameters (items and maxConcurrency) with detailed descriptions, including subdomain format and concurrency limits. The tool description adds no parameter-specific meaning beyond the schema, 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 pulls live product catalogs from Zid storefronts, listing specific fields (name, price, sale price, category, image). It distinguishes itself from siblings by explicitly targeting Zid, a Saudi/Gulf e-commerce platform, while sibling tools focus on Shopify or general web scraping.
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 when to use the tool: for pulling product data from Zid stores via public JSON feed without login, browser, or proxies. It also mentions per-call cost, which is useful context. However, it does not explicitly state when not to use it or name alternative tools, though sibling names provide implicit guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
shopify-price-change-monitordomain-health-checkerpricing_infoshopify-store-intelligencesitemap-to-knowledgestructured-extracttech-stack-change-detectortech-stack-detectorurl-to-markdownzid-store-productsClaiming proves that you control a remote MCP connector. It does not move, proxy, or interrupt the server.
Open the connector listing, choose Claim ownership, and sign in to Glama.
Complete one verification method:
GitHub identity — fastest for official registry listings. For a namespace such as io.github.alice/server, link the matching GitHub user, then choose Claim with GitHub. An organization namespace such as io.github.acme/server also needs that organization to have installed the Glama AI GitHub App and approved its permissions, because GitHub discloses organization membership only to apps it has installed. Use HTTP or DNS when it has not.
HTTP challenge — works when you can deploy a public file. Generate a token, publish the exact JSON Glama shows at /.well-known/glama.json on the same origin as the connector, then choose Check HTTP challenge.
DNS challenge — works when you control DNS but cannot change the server. Generate a token, create the exact TXT record Glama shows, wait for it to propagate, then choose Check DNS challenge.
After verification, Glama sends a confirmation email and gives you access to listing details, thumbnails, health checks, and analytics. Keep the HTTP file or DNS record in place: Glama periodically checks it and ownership remains verified while the token is discoverable.
The HTTP ownership file has this structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"claim": "glama_claim_..."
}Claim tokens are opaque, stable, and bound to the signed-in Glama account. They contain no email address or other personal information. If Glama can no longer discover a verified HTTP or DNS token, it starts a seven-day grace period before removing claim-based access. Restore the same token during that period to keep ownership verified. Never publish an email address, Glama session token, GitHub token, or connector credential as ownership proof.
If verification fails, confirm that you copied the current token exactly. The HTTP file must be public, return valid JSON with a successful HTTP response, and stay on the connector's origin. DNS changes may need more time to propagate. A claim cannot transfer to a different origin or hostname: if the connector target changes, Glama starts the grace period and the new target must be claimed separately after the previous claim is released.
For a connector linked to the official MCP Registry, registry updates continue to replace its name, description, and URL by default. After claiming, open Manage connector and enable Use Glama listing details as the source of truth if edits made on Glama should be preserved. Categories and thumbnails are always managed on Glama; registry linkage and technical connection settings continue to sync.
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
To improve your MCP server's ranking:
Claim ownership of the server listing
Complete the server profile with an accurate description and thumbnail
Provide a test profile so Glama can connect to and evaluate the server
Keep tool definitions clear and complete to earn a high Tool Definition Quality Score (TDQS)
Route real usage through the Glama Gateway; more recorded successful server uses also improve the ranking
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.
No comments yet. Be the first to start the discussion!
Add one secure layer between your agents and this server.
Most tools have clear distinct purposes, but url-to-markdown and structured-extract both fetch a single URL and could be confused; tech-stack-detector and tech-stack-change-detector are closely related but descriptions clarify the difference. Overall, the tool set is well-differentiated.
The majority of tools use lowercase hyphenated names (e.g., domain-health-checker, url-to-markdown), but pricing_info breaks the pattern with an underscore. There is also some variation in style (detector vs. to-knowledge vs. extract), but it remains readable and predictable overall.
Ten tools is well within the ideal range for a web intelligence bundle, covering domain health, store data, content extraction, and tech stack detection without feeling bloated or sparse. Each tool earns its place for specific use cases.
The surface covers major web intelligence needs: domain audits, Shopify/Zid store data, content fetching/transformation, and tech stack detection. Minor gaps exist, such as no generic price-change monitor for non-Shopify stores and no whois/backlink tools, but these are not critical for the stated purpose.