Vellium & Co Testing Lab

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the full burden. It usefully discloses the 25-seller/25-website cap and a cost advantage, which is real behavioral content. But it omits what 'check' actually evaluates, permission/auth requirements, behavior when the cap is exceeded, and the response shape.

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?

A single front-loaded sentence with no filler; the batching scope and cost hint are both useful. It is appropriately sized for a simple two-array tool, though slightly terse given the undocumented parameter formats.

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 and no annotations, so the description is the main source of context. It covers scope and limits but leaves out what a 'check' returns and the item format, which an agent needs to call it 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 0% for the two array parameters. The description names 'sellers' and 'websites' and their 25-item limits, partially mapping to the schema, but says nothing about the expected string format (IDs, domains, names) for array items.

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 ('check') and resources ('sellers and websites') plus the batching scope ('in one call'), which clearly separates it from the single-target check_seller/check_website siblings. It does not explicitly name those siblings, so it earns a 4 rather than 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?

The parenthetical '(cheapest for many checks)' implies you should use this batch tool when performing many checks instead of the single-item siblings. However, it never names the alternatives, states when NOT to use it, or clarifies what 'many' means beyond the 25-per-type cap.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the full burden, yet it omits the safety profile (read vs write), the response shape, pagination, and any rate-limit or auth notes. It hints at delta/incremental semantics but never confirms them or explains what a 'change' actually contains.

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?

It is a single short sentence with no waste, so length is appropriate. However the em-dash construction reads as two fragments rather than a front-loaded purpose statement, and the brevity comes at the cost of substance.

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 1-parameter tool with no annotations and no output schema, the description should define what is compared, the default window, and the return content. None of these are present, so an agent lacks the context to call it confidently.

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% and identifies the single parameter as a 'YYYY-MM-DD' string, so the schema does the heavy lifting. The description adds no format, default, or boundary semantics beyond it — notably it is silent on what happens when the optional 'since' is omitted.

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 largely restates the name ('changes' → 'What changed since a day') with an added hint about keeping a local copy in sync. It never identifies what resource is being compared (websites? sellers? the whole workspace) and offers no differentiation from the eight sibling tools, several of which list/check the same domain entities.

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 'keep a local copy in sync' weakly implies the sync use case, but there is no explicit when-to-use, no when-not-to-use, and no named alternative among siblings. An agent cannot tell whether this supersedes or complements 'batch' or the various list_* tools.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description must carry the full behavioral burden. It mentions an 'independent check' and 'proof', which hints at a read-only verification, but it does not state read-only status, permission requirements, rate limits, error behavior, or what happens on failure.

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 sentence that front-loads the core purpose, but it becomes a long, awkward list ('answering, price, buyers, and its paid answers checked...') that obscures meaning. It is concise in length but not well-structured for quick parsing.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With no output schema and no annotations, the description should explain return values and operational context more clearly. It attempts to list outputs vaguely ('answering, price, buyers') and notes proof, but lacks usage guidance, parameter details for id, and behavioral specifics. Minimal but not fully adequate for the tool's scope.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 50%; the 'resource' parameter is documented as the seller's URL, while 'id' lacks a schema description. The description compensates partially by clarifying that the address can be in 'any spelling' and that an id is also accepted, but it does not explain id format or constraints.

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 ('check') and resource ('one paid seller'), and specifies lookup keys (address or id). It does not explicitly differentiate itself from siblings like search_sellers or sellers_on_domain, but the core purpose is clear enough to identify the tool.

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?

No guidance is given on when to use this tool versus alternatives such as search_sellers or check_website. The description implies a single-seller lookup but offers no conditions, prerequisites, or exclusions.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the full burden, and it does disclose the kinds of signals returned (plain-agent access, per-agent door behavior, robots rules, llms.txt, history). That is real behavioral content beyond the schema. However, it says nothing about whether results are cached, how current the 'history' is, whether the domain is fetched live, or what an inaccessible/errored domain looks like, so a mutation/side-effect profile and failure behavior remain undisclosed.

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?

It is short, and the central question is front-loaded, which is good. But the trailing list of artifacts is a fragmentary noun string with no connective structure, so the reader must guess what each item means and how they relate to the answer.

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 one-parameter tool with no output schema and no annotations, the description does useful work by naming the artifacts checked, effectively sketching the return content. It still omits the shape of the response, whether it is a verdict plus evidence, and any error semantics, leaving an agent able to call it but not fully predict the result.

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?

There is one parameter and schema description coverage is 100%, with the schema itself supplying the format example (e.g. walmart.com), so baseline is 3. The description's mention of 'shopping or travel website' adds a hint about the kind of domain expected but no syntax, normalization, or subdomain guidance beyond the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description frames the tool as answering whether AI agents can use a shopping/travel website, and lists the evidence it inspects (robots rules, llms.txt, per-agent door access, history). That conveys the general intent, but it is phrased as a question and packs several loosely-related artifacts together rather than stating one clear verb+resource like 'check AI-agent access policy for a domain'. It is distinguishable in spirit from siblings such as list_websites or sellers_on_domain, but the separation is implied rather than stated.

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?

No guidance on when to call this versus alternatives is given. The description does not say whether this is for pre-flight checks before scraping a domain, or how it relates to siblings like sellers_on_domain, check_seller, or batch, nor does it mention any prerequisites or exclusions.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the full burden and does disclose the shape of the output (source, exact call, return volume, fallback), which is more than most. It omits the safety/permission profile, error or no-match behavior, rate limits, and the fact that the full-tier response surfaces paid sellers - context an agent would want before invoking.

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 content is compressed into two long sentences whose opening ('Where to go for a job') is vague and whose middle is padded with sales language ('before you spend tokens on trial and error', 'the paid sellers we rate'). The actionable part - query examples and the detail mode - is buried after the pitch rather than front-loaded.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With no output schema and no annotations, the description does enough to convey what comes back (a routed source, its call, its size, a fallback, and optionally paid sellers), but it leaves unstated what happens on no match, whether results are cached or fresh, and any authentication or licensing constraints on the returned sources.

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 already 100%, so the baseline is 3, but the description adds genuinely new information by giving example values for the required 'q' parameter that clarify the expected phrasing and granularity. The optional 'country' parameter is not addressed in the description at all, keeping this below a 5.

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 recognizable purpose: given a plain-language data need, return the best tested free official source with its call pattern and expected volume, plus a fallback. However, it frames this in marketing prose ('before you spend tokens on trial and error') rather than a crisp verb+resource statement, and it never distinguishes itself from the seller-oriented siblings (search_sellers, check_seller, sellers_on_domain).

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?

Concrete example queries ('UK company directors', 'Apple revenue', 'EU gas storage') implicitly tell the agent what kind of request this tool is for, and the detail=full note indicates a second mode. But there is no explicit when-to-use/when-not guidance and no pointer to any alternative sibling tool when this router is the wrong choice.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries the full behavioral burden, yet it discloses almost nothing: no confirmation that this is a read-only listing, no pagination or result-set size behavior, no ordering. The only partial disclosure is that results include sellers, buyers and a verification method, which is vague ('how we check 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?

It is a single compact sentence with no filler, and the core resource is front-loaded before the language note. The semicolon clause is slightly crammed and imprecise, keeping it short of a 5.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple one-parameter list tool with no annotations and no output schema, the description is minimally adequate but leaves the actual return structure ambiguous — an agent cannot tell whether category names alone come back or whether nested seller/buyer/verification data is included.

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 single parameter has a full enum, so the schema already documents lang completely. The description's 'names in your language with lang' merely restates this, adding no format, fallback, or default behavior. 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?

The resource is identifiable ('every category of paid service agents buy'), but there is no explicit verb and the phrase 'with sellers, buyers and how we check it' is ambiguous about whether it describes returned data or the tool's mechanics. It also gives no differentiation from siblings like list_websites or search_sellers.

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?

There is no statement of when to use this tool versus the sibling tools (search_sellers, list_websites, check_seller), and no prerequisites or exclusions are mentioned. The only contextual hint is the language parameter, which is already covered by the schema.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the full behavioral burden. It implies a read-only listing but never states that, and says nothing about pagination behavior, result ordering, default result count, or any auth/rate-limit 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?

A single dense sentence with the resource front-loaded and the three filter dimensions enumerated in order. The nested parentheticals are packed but each earns its place; nothing is padded.

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 6-parameter tool with no annotations and no output schema, the description covers only the filter dimensions. It omits any indication of what a result contains (the 'rating' implied by 'rated' is never described) and does not mention pagination, leaving meaningful 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?

At 67% schema coverage the baseline is 3, and the description does add real meaning by explaining the price-honesty concept ('does the price agents read match what people see') behind the prices enum. However it says nothing about limit, cursor, or detail, which the schema documents only thinly ('default 40').

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 names the resource (rated websites) and enumerates the three filters that scope it, so an agent can tell it is a filtered listing tool rather than a lookup tool. It stops short of explicitly contrasting with siblings such as check_website or sellers_on_domain, which would be needed for 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?

Usage is only implied: the mention of market/plain-agent/price filters suggests when to reach for it, but there is no explicit statement of when to use this versus check_website or search_sellers, and no exclusions or prerequisites. The routing hint ('check_website has the tables') lives in the schema, not the description.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

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 says results are 'ranked' but never states the default ranking, result shape, pagination behavior (a cursor param exists), or rate/cost limits, which are significant gaps for a 10-parameter search 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?

Two tight sentences, front-loaded with the core purpose and followed by the usage cue. Nothing is redundant, though the brevity comes at the cost of the behavioral detail noted elsewhere.

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 10 parameters, no annotations, no output schema, and partial schema coverage, this description is far too thin. An agent gets no sense of the returned result structure or pagination mechanics, which are essential 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 60%, leaving limit, cursor, answering, and min_buyers undocumented in both schema and description. The description only reaffirms single-category scoping ('inside one category') and ranking, adding no meaning to the filter or sort parameters beyond what the schema already encodes.

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?

Names a specific verb ('Find') and resource ('paid x402 data services AI agents can buy'), and scopes it to a single category with ranking. It doesn't explicitly contrast itself with siblings like check_seller or list_categories, but the resource and domain are distinctive enough to separate it from them.

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 'Use before paying any seller' gives one concrete timing cue for invocation, which is more than nothing. However, it names no alternatives and doesn't clarify how this differs from check_seller when the agent already knows a seller, leaving the when-not condition to inference.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

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 hints that sellers are ones "we check" (an ongoing monitoring notion) and that they are "paid", but says nothing about authentication, pagination, result limits, caching freshness, or whether the list is scoped to the current workspace.

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?

It is a single short fragment, which is technically economical, but brevity here comes from under-specification rather than precision — the sentence omits the core action and is not usefully front-loaded.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a tool with no annotations, no output schema, and 0% parameter documentation, the description needed to carry the full burden and instead delivers one vague clause. It gives a faint sense of scope (paid sellers per host) but leaves the return shape, limit behavior, and required vs optional usage unexplained.

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 0% for both parameters. "One host" loosely maps to the required domain parameter (a single host), but the optional limit parameter is never mentioned in either schema or description, leaving its purpose and range entirely undocumented.

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 phrase "Every paid seller we check on one host" is a noun fragment with no verb, so it never states what the tool actually does (list? fetch? monitor?). It gestures at sellers being checked on a domain, but an agent cannot cleanly separate it from siblings like search_sellers or check_seller without guessing.

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?

There is no when-to-use guidance, no conditions, and no mention of any alternative such as search_sellers or list_websites. The agent is given nothing to route on.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.