Scrape, search and extract the public web. 3,000 free credits at https://vera.waggle.ae/signup
Scored across 8 tools
Tools target distinct resources: search finds pages, scrape reads a page, and specialized extractors handle contacts, products, company profiles, SEO, sitemaps, and YouTube transcripts. Overlap is limited to company_profile versus extract_contacts/scrape for contact data, but the multi-page company focus distinguishes it.
All names use snake_case and are readable, but the set mixes verb-noun (extract_contacts), single verb (scrape, search), and noun phrases (company_profile, sitemap, seo_audit), so there is no single predictable pattern.
8 tools is well within the ideal 3-15 range for a web data extraction service; each tool covers a distinct capability and none appears redundant.
The surface covers discovery (search, sitemap), general reading (scrape), specialized extraction (contacts, products, company profile), SEO auditing, and YouTube transcripts, which is strong for a read-only web data API. Minor gaps remain for bulk operations or other structured-data types beyond products, but no critical workflow is blocked.
Given a company's domain, read its homepage and up to 3 standard pages (about, contact, team) and return a profile: name, description, logo, address, founding date, emails, phones and social links, as the company publishes them. Costs 1 credit for each page read, at most 5 credits (that many are held while it runs and the unused ones are given back); a failed call costs nothing.
| Name | Required | Description | Default |
|---|---|---|---|
| domain | Yes | The company's domain or website address, for example example.com. | |
| idempotency_key | No | Optional. Send the same key (16 to 128 letters, digits, _ . : -) to retry this exact call safely: a retry within 24 hours returns the first result and is not charged again. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With readOnlyHint/openWorldHint already covering safety, the description adds substantial non-structured behavior: page scope (homepage + up to 3 pages), the credit cost model (1 per page, max 5), that credits are held and unused ones refunded, and that failed calls are free. This is exactly the operational context annotations cannot express.
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?
Front-loaded with the core action and scope, followed by one dense cost sentence. Slightly long in the field-list clause, but every sentence carries information the agent needs.
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 read-only tool with no output schema, the description names the returned fields and discloses page limits, cost, refund, and failure behavior, so nothing critical is missing for correct invocation.
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 both domain and idempotency_key are documented in the schema. The description adds no parameter-level detail (it does not mention idempotency/retry behavior beyond what the schema states), 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?
States a specific verb (read/profile) and resource (company domain/homepage + standard pages) and enumerates the returned fields. It is clearly distinct from siblings like extract_contacts or extract_products because it returns a whole company profile rather than one field class.
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 the tool applies (you have a domain and want a broad company profile) but never names alternatives such as extract_contacts or scrape, nor states when not to use it. Usage is inferable but not explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read one public page and return the contact details it publishes: email addresses, phone numbers, social profile links and links to contact pages, each with where it was found. Published details are not verified, and linked pages are not followed (call this tool again for one). Costs 1 credit; a failed call costs nothing.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | The full public http(s) address of the page. | |
| idempotency_key | No | Optional. Send the same key (16 to 128 letters, digits, _ . : -) to retry this exact call safely: a retry within 24 hours returns the first result and is not charged again. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the readOnly/openWorld annotations, it discloses non-obvious traits: results are unverified, linked pages are never crawled, cost is 1 credit, and failed calls are free. The billing-on-failure and no-follow semantics are exactly the kind of context annotations cannot express.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three tight sentences: what is returned first, then the two caveats (unverified/no-follow), then the cost. Every clause earns its place and nothing is repeated from structured fields.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description correctly enumerates the return shape including provenance ('each with where it was found'), and covers cost and non-crawling behavior. An agent has everything needed to call and interpret it.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% and both parameters (url, idempotency_key) are documented in the schema, including the 24-hour retry billing behavior. The description adds no additional parameter meaning, so the baseline 3 applies.
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?
States a specific verb (read) plus the exact resource and scope (one public page) and enumerates the returned artifact types: emails, phones, social links, contact-page links. It is clearly distinguishable from siblings like extract_products and scrape.
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?
Gives clear operating context: it reads a single page and does NOT follow linked pages, with the explicit remedy 'call this tool again for one.' It does not, however, name siblings such as scrape or extract_products or say when one is preferable, so it stops short of full alternative routing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read one public product page and return the product data it publishes in its structured markup: name, brand, SKU or GTIN, and offers with price, currency and availability. Prices are what the page states, never guessed. Set marketplace to amazon, walmart or shopee for those product pages. Costs 1 credit; a failed call costs nothing.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | The full public http(s) address of the product page. | |
| marketplace | No | Set to "amazon", "walmart" or "shopee" for a product page on that marketplace. | |
| idempotency_key | No | Optional. Send the same key (16 to 128 letters, digits, _ . : -) to retry this exact call safely: a retry within 24 hours returns the first result and is not charged again. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=true, so the safety profile is covered. The description adds useful behavioral context beyond that: returned structured fields, the guarantee that prices are 'never guessed,' and explicit credit cost with free failed calls. It does not cover auth requirements or rate limits beyond the cost note.
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?
Four short sentences, front-loaded with the core action and return fields. The cost and price-fidelity sentences earn their place. The marketplace sentence partially repeats the schema enum, but remains useful for framing the allowed pages.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description appropriately explains the return fields and the price-fidelity behavior. It also covers cost and failure charging. A minor gap remains around behavior when a page lacks structured markup, but overall it is complete enough for a read-only extraction 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 description coverage is 100%, so the schema already fully documents url, marketplace, and idempotency_key. The description only restates the marketplace enum values and adds no syntax or format detail beyond what the schema provides. 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 states a specific verb and resource: 'Read one public product page and return the product data it publishes.' It lists the exact returned fields (name, brand, SKU/GTIN, offers with price, currency, availability), which makes the tool's scope obvious. It does not explicitly differentiate itself from generic siblings like scrape or from extract_contacts, so it stops short of a 5.
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 gives clear context for use: one public product page, with marketplace values for Amazon, Walmart, or Shopee pages. It also adds cost guidance. However, it never states when not to use this tool or names an alternative such as scrape for non-product pages, so exclusions are missing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read one public web page and return its content: the main text (as Markdown with response_format="markdown"), links, metadata and a quality score, plus the raw HTML if you ask (return_html). Set render=true for pages that build their content with JavaScript, or mode="auto" to render only when a plain fetch comes back empty. extract pulls named fields out with CSS selectors. Costs 1 credit for a plain fetch and 5 credits when the page is rendered; a failed call costs nothing. Pages that disallow automated access or need a login cannot be read.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | The full public http(s) address of the page. | |
| mode | No | "manual" (the default) does what render says. "auto" fetches the page plainly and renders it only when it looks empty; it holds up to max_cost credits and charges what it used. | manual |
| render | No | Run the page's JavaScript in a browser first, for pages that build their content in the browser. Costs more. | |
| country | No | Two-letter country code for the language headers of the request, for example ae or gb. It does not route the request through that country. | |
| extract | No | Named fields to pull out with a CSS selector, for example {"heading":{"selector":"h1"},"links":{"selector":"a","attribute":"href", "multiple":true}}. One tag, class, ID or attribute selector each. Static pages only. | |
| wait_ms | No | Milliseconds to wait after the page loads. Needs render=true. | |
| max_cost | No | With mode=auto, the most to spend: 1 never renders, 5 may render. | |
| wait_for | No | A CSS selector to wait for before reading. Needs render=true. | |
| return_html | No | Also return the page's raw HTML in data.html (up to 2 MB). Not with extract. | |
| idempotency_key | No | Optional. Send the same key (16 to 128 letters, digits, _ . : -) to retry this exact call safely: a retry within 24 hours returns the first result and is not charged again. | |
| response_format | No | Use "markdown" to get the page's main content as Markdown in data.markdown, the best form for reading or summarising. "all" (the default) and "text" return the standard fields: text, links, metadata and a quality score. | all |
| min_quality_score | No | Refuse the page, at no charge, when its quality score is below this. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only declare readOnly and openWorld, but the description adds the cost model (1 credit plain fetch, 5 when rendered, failed calls free), the min_quality_score no-charge refusal, and the access restrictions that silently limit which URLs work. These are behavioral facts an agent cannot get from the annotations or schema alone and they affect tool choice.
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 core capability and the return values are front-loaded, and the wordiest sentences (render/mode) each carry distinct decision-relevant content. It is dense with parenthetical parameter names, but no sentence is pure filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 12 parameters, no output schema, and a nested extract object, the description compensates well by naming the return fields and the data.html size cap, and by clarifying the extract versus return_html constraint. It is adequate; only minor interaction details (e.g., wait_ms/wait_for with extract) are left entirely to the schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3, but the description goes further by explaining how render, mode, and max_cost interact (auto renders only when a plain fetch comes back empty, capped by max_cost) and links rendering to the 5-credit cost. minor additions like the country header caveat remain schema-only.
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?
States a concrete verb and resource ("Read one public web page") and enumerates the returned artifacts (main text as Markdown, links, metadata, quality score, optional raw HTML), so the agent knows exactly what it gets. It does not explicitly differentiate itself from siblings such as extract_contacts or search, which is the only gap.
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?
Gives clear selection conditions between render=true, mode="auto", and a plain fetch, plus extract for named fields, and states an explicit exclusion: pages that disallow automated access or require a login cannot be read. It stops short of naming which sibling tool to use instead for a different task.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search Google and return the results: titles, URLs and snippets, plus Google's own answer boxes, People Also Ask and related searches when it shows them. vertical picks web (the default), news or videos. Returns up to 100 results per call (10 by default), with country and language. Costs 3 credits per call whatever the vertical or limit; a failed search costs nothing. Results are links and snippets: use scrape to read a page.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | How many results to return (10 by default). The price is the same whatever the number. | |
| query | Yes | What to search for. Quoted phrases and site: operators are kept. | |
| country | No | Two lowercase letters for the search market, for example us, gb or ae (default "us"). | us |
| language | No | Two lowercase letters for the result language, for example en or ar (default "en"). | en |
| vertical | No | "web" (the default), "news" or "videos". | web |
| idempotency_key | No | Optional. Send the same key (16 to 128 letters, digits, _ . : -) to retry this exact call safely: a retry within 24 hours returns the first result and is not charged again. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only cover read-only and open-world; the description goes well beyond them by disclosing cost (3 credits per call regardless of vertical or limit), that failed searches are free, the safe-retry/idempotency behavior, and the exact composition of the result set including answer boxes and related searches. That is the kind of behavioral context an agent needs to budget and sequence calls.
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?
Four tight sentences, each carrying distinct information: what comes back, vertical selection, limits/locale, cost, and the hand-off to scrape. The cost and failure-cost facts are stated early and nothing is padding.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description takes on the burden of describing the return shape and does so concretely, plus covers pricing, retry safety, result caps and sibling routing. An agent has everything needed to call this 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 schema already documents limit, query operators, country, language, vertical and idempotency_key. The description mostly restates these (default limit of 10, up to 100, country/language) rather than adding syntax or semantics beyond the schema, so baseline 3 applies.
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?
States a specific verb and resource ('Search Google and return the results') and immediately enumerates the return payload (titles, URLs, snippets, answer boxes, People Also Ask, related searches). It also names the sibling it is not ('use scrape to read a page'), so an agent can separate it from scrape/extract_* without opening any schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly routes the agent away from this tool when full page content is needed ('Results are links and snippets: use scrape to read a page') and explains the vertical selector for web/news/videos. It gives clear context but no exclusions around when search is the wrong choice for entity/company lookups covered by company_profile.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Audit one public page's technical SEO and how ready it is for AI search: title, description, canonical, robots and indexing directives, headings, links, images, structured data and a score. Costs 1 credit, or 5 credits with render=true (audited after its JavaScript runs); a failed call costs nothing.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | The full public http(s) address of the page. | |
| render | No | Audit the page after its JavaScript has run. Costs more. | |
| country | No | Two-letter country code for the language headers of the request, for example ae or gb. It does not route the request through that country. | |
| idempotency_key | No | Optional. Send the same key (16 to 128 letters, digits, _ . : -) to retry this exact call safely: a retry within 24 hours returns the first result and is not charged again. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Adds behavior beyond the annotations: the exact credit cost (1, or 5 with render=true) and the guarantee that a failed call is free, plus that render means the audit happens post-JS execution. Annotations already declare readOnly/openWorld, so this is solid added context, though it does not describe latency or result freshness.
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, front-loaded with the audit scope, followed by the cost/pricing clause. No filler; every phrase carries information the agent needs.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description compensates by enumerating the audited fields and mentioning the score, and it covers cost and failure behavior. An agent has enough to decide and call 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 coverage is 100%, so the baseline is 3; the description earns an extra point by quantifying the render cost (5 credits) and restating the post-JavaScript semantics in cost terms, which the schema only vaguely calls 'costs more'.
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?
States a specific verb (audit) and resource (one public page) and enumerates exactly what is examined: title, description, canonical, robots/indexing directives, headings, links, images, structured data, plus a score. Clearly distinct from scrape/search/sitemap siblings which are not audits.
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?
Scopes usage to a single public page and gives the key selection criterion for the render flag (audit after JavaScript runs). It does not explicitly say when to prefer this over sibling tools like scrape or sitemap, so it falls short of full alternative routing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read a site's sitemap.xml (or a sitemap index) and return the page addresses it lists, up to limit (100 by default), optionally only those containing some text. Costs 1 credit; a failed call costs nothing.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | The address of the sitemap.xml, or of a sitemap index. | |
| limit | No | How many page addresses to return (100 by default). | |
| filter_pattern | No | Keep only addresses that contain this text. | |
| idempotency_key | No | Optional. Send the same key (16 to 128 letters, digits, _ . : -) to retry this exact call safely: a retry within 24 hours returns the first result and is not charged again. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and openWorldHint, so the safety profile is covered. The description adds genuinely new behavioral context beyond annotations: the 1-credit cost and the fact that a failed call is free, which matters for call planning. It stops short of describing return shape or pagination behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two dense sentences with zero filler. The core action and its scope are front-loaded, and the cost caveat is appended compactly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description correctly carries the burden of stating what comes back ('the page addresses it lists') and discloses cost, which is the main decision-relevant fact. It could say more about ordering or truncation behavior when limit is hit, but nothing essential to calling it correctly is missing.
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 all four parameters (including the idempotency key's 24-hour retry semantics) are already fully documented in the schema. The description restates limit's default of 100 and the filter behavior in plain language but adds no syntax or meaning beyond what the schema provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource: reads a site's sitemap.xml or sitemap index and returns the page addresses listed. The resource is specific enough to separate it from generic siblings like scrape or search, but it never explicitly names which sibling to prefer for non-sitemap page discovery.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The usage context is implied rather than stated: it is clearly for sitemap.xml/sitemap-index inputs, and the credit-cost note ('costs 1 credit; a failed call costs nothing') helps an agent weigh the call. However, there is no explicit when-to-use/when-not guidance or named alternative (e.g. scrape for pages not in a sitemap).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Return the transcript of one public YouTube video as text. Costs 6 credits per started minute of video (a 10-minute video costs 60), up to 45 minutes. A video that cannot be transcribed, or any failure, costs nothing.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | The link of a public YouTube video, like https://www.youtube.com/watch?v=... | |
| idempotency_key | No | Optional. Send the same key (16 to 128 letters, digits, _ . : -) to retry this exact call safely: a retry within 24 hours returns the first result and is not charged again. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only declare readOnlyHint and openWorldHint; the description goes well beyond them by disclosing the exact billing model (6 credits per started minute, with a 10-minute worked example), the hard 45-minute ceiling, and the failure-charge policy ("a video that cannot be transcribed, or any failure, costs nothing"). This is exactly the kind of cost/limit context an agent needs before committing a call.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three tight sentences, front-loaded with purpose then cost then failure policy. No filler and nothing repeated from the title.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description does state the return format ("as text"), and it covers cost, length limits, and failure behavior for a paid external call. Minor gap: it does not mention latency, whether long videos are rejected upfront, or how the transcript is formatted (timestamps vs plain prose), which would help an agent set expectations.
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 both url and idempotency_key are already fully documented in the schema. The description adds only the implicit constraint that the video must be public, matching the schema's wording; it says nothing about retry/idempotency semantics beyond what the schema covers, so baseline 3 applies.
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?
Specific verb ("Return the transcript") plus specific resource ("one public YouTube video") plus output form ("as text"). Easily distinguished from siblings like scrape, search, or extract_contacts, which have nothing to do with YouTube transcription.
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?
Usage is implied rather than stated: the agent can infer this is the tool for transcribing a YouTube URL, and the 45-minute cap implicitly describes when the tool will not work. However, no alternatives are named and there is no explicit when-to-use/when-not framing.
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.
company_profileextract_contactsextract_productsscrapesearchseo_auditsitemapyoutube_transcriptWeb search, browser automation, scraping, crawling and CAPTCHA solving for AI agents.
Web search, scraping, Google Trends and data lookups. Paid per call in USDC on Base via x402.
Search the web and extract clean, readable text from webpages. Process multiple URLs at once to sp…
Public web data for AI agents: scrape any page, plus Google, TikTok, Instagram and Amazon as JSON.
Add one secure layer between your agents and this server.