Revexa: B2B buying signals

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint, so the safety profile is fully covered. The description adds the payload contents (price by region, trial, links) but says nothing else behavioral, such as whether pricing is live or static, which is a minor gap given annotation coverage.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

A single sentence that front-loads the product identity and then lists the content categories. It is somewhat run-on, especially the nested clause about finding companies and reaching people, but nothing is redundant.

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 parameterless informational tool with no output schema, the description enumerates the returned content well enough for an agent to decide to call it. It could note whether pricing/link data is current, but that is a minor omission.

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 takes zero parameters, so the schema carries no semantics to supplement; the baseline of 4 applies. The description correctly signals that no filtering or scoping input is needed.

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 a specific resource (facts about the Leo by Revexa product) and enumerates exactly what those facts cover: capabilities, regional pricing, trial, and links. It is unmistakably distinct from the sibling tools, which all retrieve third-party company/funding data rather than product info.

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: an agent can infer it is for when a user asks about Leo/Revexa, its price, or a trial. There are no explicit trigger conditions and no statement of when not to call it or what to use instead.

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?

Annotations already declare readOnly, idempotent, openWorld and non-destructive, so the safety profile is covered. The description adds genuinely useful behavior: the source is a CC0 public job board, staffing/recruitment agencies are filtered out, and the data reflects ads open "right now" (freshness). It does not describe result shape or ordering, but the annotation bar is lower here.

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 sentences, each carrying distinct information: what it returns, the source and its license, the agency exclusion, then the filter and use case. Front-loaded with the core purpose and free of filler or repetition.

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 zero-required-parameter read tool with rich annotations and a 100% documented schema, the description supplies everything an agent needs: dataset provenance, curation rule (agencies removed), freshness, and the optional filter. No output schema exists, so return-value detail is appropriately not required here.

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%: limit and county are both fully documented in the schema, including the county enum values. The description only restates that county filtering is optional, adding no syntax or semantics beyond the schema, 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 (lists), a precise resource (Swedish companies with open B2B salespeople job ads), and the data source (Platsbanken). This clearly separates it from siblings like find_startups_hiring_sales and recent_b2b_funding_rounds, which cover different segments and datasets.

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?

"Use it to find companies that are building up their sales teams in Sweden" gives a clear use case, and the mention of the optional county filter frames the scoping choice. No sibling is named as an alternative and no when-not-to-use condition is given, so it stops short of a 5.

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?

Annotations already declare readOnly, idempotent, openWorld and non-destructive, so the safety profile is covered. The description usefully adds behavior beyond that: the data source (public job boards), the freshness cadence (updated weekly), and the fact that only currently-open roles are returned.

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 the core purpose followed by filters and freshness. Every clause adds information; nothing is redundant 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 should ideally sketch the returned fields (company, role, job link), which it does not. For a simple filter-only search tool with full annotation coverage and a well-explained taxonomy, it is otherwise complete.

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 only 33% (region and limit have no schema descriptions), so the description carries real weight: it spells out the role taxonomy (SDR, BDR, account executive, head of sales) and the region options in prose. Only limit meaning is left to the schema, which is nearly self-evident.

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 gives a specific verb (Lists) plus a well-scoped resource (venture-backed B2B YC startups with open sales roles), and names the source (public job boards) and freshness. It implicitly separates itself from find_companies_hiring_salespeople_sweden via the YC/B2B framing, but never explicitly routes the agent to a sibling, 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 tells the agent which filters exist (region, role type) and their accepted values, which implies how to narrow results, but gives no when-to-use/when-not guidance and never contrasts with the sibling tools. Usage is inferred rather than stated.

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?

Annotations already cover readOnly/idempotent/openWorld/destructive, so the bar is lower, yet the description adds genuinely useful traits: the upstream sources (tech.eu, EU-Startups, TechCrunch) and the weekly collection cadence, which tells the agent the data is a curated snapshot rather than a live query. It stops short of noting update lag or whether results are ordered.

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?

One sentence, front-loaded with the verb and scope, with the returned fields and the data provenance packed in without waste. Nothing is padded or 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 only two optional params, no nested objects and no output schema, the description covers the essentials: scope, geography, cadence, fields returned and sources. It would be fully complete with a note on freshness/lag or result ordering, but that is a minor gap for a read-only list 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 0%, but the semantics are largely recoverable from structured data: the region enum values are self-describing, and limit carries default/min/max constraints. The description reinforces the region dimension ('Europe and the US') but says nothing about how region='any' behaves or what limit actually caps, so it does not fully compensate.

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 ('Lists B2B companies... that announced funding rounds this week') plus the geography and cadence. The scope is narrow and unambiguous, and the nearby siblings (about_leo, find_startups_hiring_sales) are so different that no explicit disambiguation is needed.

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 'this week' + 'collected weekly' framing implies the appropriate use case (a recurring weekly digest rather than historical lookup), but the description never states when to use this versus another tool, nor any exclusion such as 'this does not cover earlier weeks'.

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