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.
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.
Average 3.9/5 across 9 of 9 tools scored.
Each tool targets a distinct aspect of web intelligence: domain health, tech stack, Shopify, sitemap, structured data, etc. No two tools perform the same function, and the change detector is clearly differentiated from the base detector.
Most names use hyphens (e.g., domain-health-checker), but pricing_info uses an underscore, breaking consistency. Additionally, the names are descriptive noun phrases rather than following a strict verb_noun pattern, leading to a mix of styles.
With 9 tools, the server covers a broad yet focused scope of web intelligence tasks without being overwhelming. Each tool earns its place, and the count is well-suited for the domain.
The tool set covers core web intelligence needs (domain health, tech stack, product extraction) but lacks general crawling or security scanning. Minor gaps exist, such as no WHOIS or SEO analysis, but the main workflows are supported.
domain-health-checkerAInspectBulk-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?
With no annotations, the description carries the burden. It discloses parallel processing via maxConcurrency, cost per call, and the specific checks performed. It does not mention rate limits or read-only nature, but core behavior is well explained.
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 extremely concise with two sentences. The first sentence covers core functionality and specific checks; the second adds value with use case and pricing. 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 tool checks multiple aspects (DNS, SSL, SPF, DMARC) and no output schema, the description lists these checks but lacks detail on output format. Still, the agent can infer expected results from the listed features.
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 has 100% description coverage for both parameters. The description adds context about bulk audit and concurrency but does not significantly enhance parameter understanding beyond the schema's own descriptions.
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 bulk audits of domains checking DNS records, SSL expiry, SPF, and DMARC. The verb 'audit' and resource 'domains' are specific, and it distinguishes itself from sibling tools focused on tech stacks or shop data.
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 explains when to use: to find domains with email issues, spoofing risks, or expiring certificates proactively. It does not explicitly mention when not to use or alternatives, but the context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
pricing_infoAInspectFree — 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?
With no annotations provided, the description carries full burden but only reveals that the tool is 'Free' and lists items. It does not disclose potential behavioral traits such as authentication requirements, rate limits, or response caching, leaving gaps in transparency for a simple 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description consists of two efficient sentences: the first specifies the tool's function and output, the second provides a contextual usage hint. No wasted words or irrelevant 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?
Given no parameters and no output schema, the description reasonably explains the output (list of paid tools with price, payTo, network) and usage context. However, it lacks details on the exact structure or format of the output, which could improve 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?
The tool has zero parameters and schema coverage is 100%, so the description does not need to explain parameters. Baseline for 0 parameters is 4, and the description adequately fulfills this by not requiring additional parameter information.
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 lists every paid tool in the 'web-intel' bundle with specific details (price, payTo address, network), distinguishing it from sibling tools that perform different functions like domain checking or extraction.
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 explicit usage context by advising to call this tool first if the agent does not have a wallet ready, though it does not mention when not to use it or list alternative tools for related tasks.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
shopify-price-change-monitorAInspectWatches 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?
With no annotations, description discloses incremental behavior, first run baseline, pricing, and scope per run. Could add detail on frequency or result format, but sufficient for core transparency.
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 plus pricing, front-loaded with main purpose, 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?
For a tool with 3 params and no output schema, description covers purpose, behavior, and pricing; lacks return format details but adequate for core use case.
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; description adds context about pricing and baseline behavior but not parameter-specific details 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?
The description clearly states the tool watches a Shopify catalogue and returns only products with price or availability changes, distinguishing it from sibling tools like pricing_info or 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?
The description implies usage for monitoring changes over time and mentions the first run baseline, but does not explicitly contrast with alternatives or state 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.
shopify-store-intelligenceAInspectConfirm 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?
No annotations are provided, so the description carries the full burden. It discloses it's a public, API-key-free, and cost-bearing operation with a 'rough revenue-band heuristic,' implying approximation. However, it does not detail error behavior, rate limits, or idempotency, leaving gaps in transparency.
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 with no redundancy. The first sentence defines purpose and outputs; the second adds cost and authentication info. 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?
Despite lacking an output schema, the description enumerates returned data elements (product count, price range, etc.) and mentions the revenue-band heuristic. It covers key aspects for a simple tool, though it could add error handling for non-Shopify sites.
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 marginal value beyond the schema, e.g., clarifying 'one row per site' for the websites parameter. No significant new semantics are introduced for the parameters.
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 purpose: confirming Shopify sites and extracting store intelligence (product count, price range, etc.). It differentiates from sibling tools like 'tech-stack-detector' by specifying it goes beyond detection to pull detailed public data.
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 public Shopify store data via 'No login, no Shopify API key', and mentions cost. However, it does not explicitly state when to use this versus alternatives like 'tech-stack-detector' or 'domain-health-checker', nor provide when-not-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
sitemap-to-knowledgeAInspectGive 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?
No annotations provided, but description explains the process steps and constraints (no browser, LLM, API key) and pricing. It does not detail error handling or limits beyond schema maxConcurrency, but is fairly transparent.
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?
Description is short (two sentences), front-loaded with the command 'Give it a domain.' The process is explained in a single sentence. Slightly run-on but efficient.
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 mentions 'one dataset row per chunk' but does not specify the exact structure or return format. The input schema is well-covered, but output details are vague. Adequate but could be improved.
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 descriptions for both parameters. The description adds no additional meaning beyond the schema; it only restates the purpose of the tool. 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: takes a domain, reads sitemap, fetches pages, strips to clean text, splits into ~1000-char chunks for vector store embedding. It distinguishes from siblings like url-to-markdown by targeting full-site processing and chunking.
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 preparing website content for embedding into a vector store, noting no browser, LLM, or API key needed. It does not explicitly contrast with sibling tools or state when not to use, but the use case is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
structured-extractBInspectTurn 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?
Since no annotations are provided, the description bears full responsibility. It reveals deterministic extraction, zero LLM calls, and cost per call. However, it omits behavioral traits like failure modes for invalid URLs, rate limits, or response structure beyond the listed fields.
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 core function and efficient, but includes pricing and payment details ($0.01/call, USDC) that are tangential to tool selection. Still, it remains compact and informative.
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 partially compensates by listing extracted fields. However, it does not specify the JSON structure (e.g., array of objects), error handling for failed URLs, or concurrency behavior beyond the schema default. Adequate but incomplete for an agent to fully anticipate outputs.
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 has 100% description coverage for all three parameters. The description restates the list of extractable fields, aligning with the 'fields' parameter, but adds no new semantic detail beyond the schema. It meets the baseline expectation.
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 converts URLs to structured JSON with specific fields, and mentions deterministic regex extraction and low cost. However, it does not explicitly differentiate from sibling tools like url-to-markdown, relying on the 'structured' vs 'markdown' implication.
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 says the tool is 'built for AI agents that need one page turned into typed data, cheaply,' giving a usage context. But it lacks explicit when-not-to-use instructions or mentions of alternative tools, such as url-to-markdown for raw markdown or LLM-based extractors for complex reasoning.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
tech-stack-change-detectorAInspectDetect 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?
With no annotations, the description carries full burden. It discloses no browser/proxies, and cost, but omits details on error handling, data sources, rate limits, or what happens on failure. Adequate but not comprehensive.
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 packed into one efficient paragraph, front-loading purpose and then cost. It is concise without wasted words, though a bit dense for quick scanning.
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 is provided, so the description should cover return values. It does not describe the output format or structure, which is a gap. Param descriptions are thorough, but the tool's output remains unspecified.
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% but the description adds significant value by explaining the diff form (pipe-separated) and the behavior difference between bare and diff entries. This goes beyond the schema documentation.
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 detects current website technologies and diffs against a previously-seen stack. It specifies categories (CMS, ecommerce, etc.) and notes it requires no browser/proxies/login. The differentiation from sibling 'tech-stack-detector' is evident through the diff feature.
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 explains when to use (detect changes) and provides input format examples. It mentions cost ($0.01/call) but does not explicitly state when not to use or suggest alternatives. The sibling tools context suggests alternatives like 'tech-stack-detector' exist for simpler needs, but this is not directly referenced.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
tech-stack-detectorAInspectDetect 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?
With no annotations, the description carries full burden. It discloses the method (public HTML/HTTP headers, no browser/proxies/login) and pricing. It does not mention failure modes or rate limits, but the maxConcurrency parameter hints at parallel processing.
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 (four sentences) and front-loaded with the core function. Pricing information adds minor clutter but does not detract significantly.
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 two simple parameters, no output schema, and no annotations, the description adequately covers purpose and method but lacks details about the return format or error handling, which would be helpful for a complete 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?
Schema coverage is 100% with clear descriptions for both parameters. The description adds no additional meaning beyond the schema, 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 clearly states the tool detects technologies (CMS, ecommerce, etc.) from public HTML/HTTP headers. It lists specific technology categories and distinguishes from siblings like 'tech-stack-change-detector' by focusing on a single snapshot.
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 explicit usage context ('Built for sales targeting and competitive research') and implies lightweight operation ('No browser, no proxies, no login'). It does not explicitly contrast with siblings, but the context is clear enough.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
url-to-markdownAInspectFetch 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?
No annotations exist, so the description carries the burden. It discloses stripping scripts/nav/ads, preservation of structure, and mentions cost and lack of browser/LLM/API key. However, it does not mention error handling, rate limits, or response format, leaving gaps.
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 core purpose, and each sentence adds value. The pricing info is secondary but not redundant. Could be slightly shorter, but overall 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?
While the purpose and schema are clear, there is no output schema and the description does not specify the return format (e.g., array of Markdown strings vs. concatenated text). For a tool accepting up to 100 URLs, this omission is notable.
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 good parameter descriptions. The tool description adds no additional parameter meaning beyond what the schema already provides, 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 clearly states the tool's purpose: 'Fetch any URL and convert it into clean, LLM-ready Markdown'. It uses specific verbs and resources, and distinguishes itself from sibling tools which focus on domain health, pricing, and store intelligence.
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 RAG pipelines and AI agents, but lacks explicit guidance on when not to use or alternatives among siblings. No direct similar tool exists, but no exclusions are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
zid-store-productsAInspectPull 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?
With no annotations, the description provides important behavioral context: it uses a public JSON feed, requires no authentication, and mentions cost per call. It lacks details on rate limits or error handling but is still informative.
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 three sentences, each providing key information: what it does, the platform context, and cost. No unnecessary 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 and annotations, the description covers the data retrieved, source, and authentication status. It lacks output structure details but is still fairly complete for a simple catalog pull.
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?
Both parameters have descriptions in the schema (100% coverage). The overall description does not add new meaning beyond what the schema provides for the parameters.
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 purpose: to pull live product catalogs (name, price, sale price, category, image) from Zid storefronts. It explicitly mentions the source (public JSON feed) and distinguishes from siblings by targeting a specific e-commerce platform.
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 Zid stores and mentions ease of use (no login, browser, proxies), but does not explicitly state when to use this tool over siblings or provide exclusion criteria.
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.
No comments yet. Be the first to start the discussion!
