Web, EU power and SEC data tools

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 useful behavioral facts: the identifier can be an id, package name, or store URL, and it lists the fields returned. However, it says nothing about failure behavior for invalid apps, permission/auth requirements, or rate limits, so the safety and error profile remains opaque.

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 compact sentences with zero filler; the resource, sources, and acceptable identifier formats are front-loaded before the use-case hint. Every clause 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?

An output schema exists, so enumerating return values is a bonus rather than a requirement, and the description covers inputs and scope adequately. The only real gap is the unexplained 'country' parameter, which an agent must infer from the schema alone.

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%, so the description must carry the parameter semantics. It does a good job for the required 'app' parameter by enumerating three accepted identifier forms, but the 'country' parameter (and its 'us' default) is never mentioned anywhere, leaving half the inputs 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?

Names the resource (mobile app details), the supported sources (App Store / Google Play), and enumerates the returned fields (developer, rating, installs, price, etc.), which is much more specific than the title. It distinguishes itself from app_store_search and app_store_reviews only implicitly through the word 'details', but the field list makes the scope unambiguous.

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 for app or competitor research' gives a general context but no explicit when-to-use/when-not-to-use guidance. It never says to use app_store_search to first find an app or app_store_reviews to get reviews, so the routing among the three app_store siblings is left 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 exist, so the description carries the full behavioral burden. It discloses the two stores and the returned fields, but says nothing about auth requirements, rate limits, pagination, or whether a store URL and a package name resolve to the same app. The return-field listing is largely redundant with the output schema.

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 resource and sources before the use case. Slight waste in re-listing return fields that the output schema already covers, but no 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 zero annotation coverage and 0% schema description coverage, the description should do more: the valid values and behavior of 'sort', the ceiling for 'limit', and country semantics are absent. The output schema covers return values, so the description's field list adds little, leaving real gaps for an agent to guess at.

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%, so the description must compensate. It usefully explains that the required 'app' parameter accepts an app id, package name, or store URL — genuinely additive — but leaves 'sort', 'limit', and 'country' undocumented in both schema and description, so compensation is only partial.

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 resource (user reviews of a mobile app) and its two sources (Apple App Store, Google Play), and enumerates the returned fields. The siblings are entirely different data domains, so no sibling confusion arises; the purpose is unmistakable.

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 to analyse app feedback" implies the intended use case but gives no when-to-use vs when-not conditions, no prerequisites, and no alternatives. Since no sibling overlaps this domain, the missing exclusions are less costly, leaving implied usage rather than explicit routing.

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 exist, so the description carries the full burden. It usefully discloses that results are rank-ordered, capped at 50, and include full details, and that the store value is 'google' or 'apple'. It says nothing about rate limits, auth, pagination, or whether this is strictly a read-only operation.

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, zero filler. The capability statement comes first and the usage guidance follows, so an agent can stop reading after sentence one if it only needs the what.

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?

An output schema exists, so return-value detail need not be spelled out, and the description still summarizes the shape (ranked apps with full details). The main omission is any mention of the country parameter, which an agent must discover from the schema alone.

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%, so the description must compensate. It clarifies the store parameter's accepted values ('google or apple') and implies a 50-result ceiling on limit, but never mentions the country parameter or the limit default of 20, leaving one of four parameters fully 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?

States a specific verb (search) and resource (App Store / Google Play apps), plus what is returned: ranked apps with full details. It functionally separates itself from siblings app_store_details and app_store_reviews, though it never names them explicitly.

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 for ASO keyword research or finding competing apps" gives positive use cases, but there are no exclusions or explicit routing to the sibling detail/review tools. Usage is implied rather than prescribed.

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 does useful work by disclosing the temporal limit ('up to a year of historical prices'), the date format, and the economic outputs produced. It omits what actually happens if the range exceeds a year (truncation vs. error) and whether payback is returned when capex is left null.

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 what is computed, then the use case, then the date-format caveat. No filler and nothing 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?

An output schema exists, so return-value detail is not needed. However, for a six-parameter financial tool with no annotations, the description leaves gaps around the one-year window behavior, duration (MW/MWh) semantics, and the optionality of capex_per_kwh.

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% across six parameters, so the description must compensate. It clarifies zone semantics and the YYYY-MM-DD date format for start/end, and the mention of 'revenue per MW' and 'payback' implicitly ties to power_mw and capex_per_kwh, but power_mw, energy_mwh, and capex_per_kwh defaults/units are never explained.

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 computation (day-ahead arbitrage revenue), the resource (BESS in a European bidding zone), and the output unit basis (annualised revenue per MW, cycles, payback). This is clearly distinguishable from siblings like eu_power_prices or evm_gas_fees, which return raw market data rather than a project-economics metric.

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 when sizing or screening a battery project or comparing zones' gives concrete selection contexts. There are no explicit exclusions or named alternatives (e.g., when to prefer eu_power_prices for raw prices), so it stops short of a full when/when-not statement.

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 and does substantive work: it discloses the 31-day maximum range, that times are in local time, and that output includes daily min/max/mean plus cheapest/priciest N-hour windows. It does not state units/currency, data freshness, or whether future days beyond day-ahead are available, which keeps it below a 5.

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 tightly packed sentences: the first front-loads what the tool returns and its constraints, the second covers when to use it. No filler and nothing 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?

An output schema exists, so return values need not be spelled out, and the description covers purpose, constraints, and usage triggers adequately for a 4-parameter read tool. The remaining gap is peripheral detail such as price units/currency and accepted date formats.

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%, so the description must compensate, and it largely does: the zone examples effectively enumerate valid zone values, 'up to 31 days in local time' bounds the start/end parameters, and 'cheapest and priciest N-hour window' explains window_hours. It omits date string format and the null/default behavior of start and end, so not a full 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 precise verb+resource ('Day-ahead wholesale electricity prices') and scopes it to a European bidding zone, even listing example zone codes (DE-LU, FR, NL, AT, BE, PL). An agent can immediately distinguish this from unrelated siblings like evm_gas_fees or us_company_filings.

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 concrete triggering scenarios: 'Use when scheduling EV charging, heat pumps or batteries, or asked what power costs tomorrow.' That is clear when-to-use guidance. It stops short of explicit when-not-to-use or naming an alternative sibling (e.g., bess_arbitrage_revenue), so it is a 4 rather than 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?

No annotations are provided, so the description must carry behavioral disclosure. It usefully states that results are 'current' and itemizes the returned fee components, but it says nothing about freshness/refresh cadence, whether unsupported chain values error out, or any rate limiting. For a read-only data tool this is acceptable but leaves 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?

Two tight sentences: the first front-loads what is returned, the second front-loads the usage cue. Every clause earns its place with no 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?

An output schema exists, so return values need not be explained, yet the description still summarizes them usefully. It covers chains, units (gwei), fee tiers, and the transfer-cost estimate, leaving only the exact accepted chain-string format 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 description coverage is 0% and there is no enum on the single 'chain' parameter, but the description enumerates the five valid chains, which is exactly the missing information. It does not specify the exact string format expected (e.g., lowercase vs. display name), which is a minor residual ambiguity for the only required parameter.

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 (current gas fees) and explicitly enumerates the supported chains (Ethereum, Base, Arbitrum, Optimism, Polygon) plus exactly what fields are returned. No sibling tool covers gas or EVM data, so separation is trivially clear and the verb/resource pairing is unambiguous.

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 a concrete usage cue: 'Use before sending a transaction,' which tells the agent when this tool is relevant. It does not name exclusions or alternatives, but no sibling tool is a plausible substitute, so the guidance is sufficient without being exhaustive.

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. It usefully discloses the return format and metadata fields and restricts scope to 'public' pages, but says nothing about authentication, rate limits, dynamic/paywalled pages, or failure modes.

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 with zero waste; the core action and return format are front-loaded before the usage note.

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?

An output schema exists, so return values are covered elsewhere, but with no annotations and 0% schema description coverage the description leaves the 'links' parameter undocumented and provides no operational limits. Adequate for a simple read tool but incomplete on parameters.

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 two parameters. The description only implies the 'url' parameter through 'from a URL' and entirely omits the 'links' boolean parameter and its default, so it fails to compensate for the schema gap.

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 ('Read a public web page') and describes the exact return content (clean Markdown with title, author, publish date, language). Sibling tools are unrelated, so no differentiation 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?

Provides clear usage context: 'Use when you need to read, quote or summarise an article or docs page from a URL.' It does not state when not to use the tool or name alternatives, but the condition is explicit enough for selection.

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 supplied, so the description carries the full burden. It discloses recency ordering ("Latest") and that results include links, and reads implicitly as a read-only public-data lookup, but it never states read-only-ness, result freshness/coverage limits, or how many filings come back by default.

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 no filler, and the core action and source are front-loaded before the optional filter detail. It is close to optimally sized, with only the trailing usage sentence verging on optional.

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?

An output schema exists, so return field details are not needed here. For a simple retrieval tool the description covers source, key, filter, and intent, but silence on the limit parameter's role and on whether multiple form codes can be passed leaves small operational gaps.

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

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

Schema description coverage is 0%, so the description must compensate. It does so well for two of three parameters: "by ticker" pins the required key, and the parenthetical 10-K/10-Q/8-K/form 4/13F-HR/S-1 list gives far more meaning than the bare string schema. The limit parameter and multi-form syntax (the schema allows a single string) are left unexplained.

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+resource: retrieving the latest SEC EDGAR filings for a US-listed company keyed by ticker, with the optional form filter named. It does not explicitly contrast itself with the sibling us_company_fundamentals, so it falls short of the top mark despite being unambiguous.

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 for recent disclosures or insider filings" gives a usage context, but there is no when-not guidance and no named alternative (e.g., use us_company_fundamentals for financial statement data). The agent must infer the boundary with siblings.

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 usefully discloses the data source, that values are as-filed rather than estimated, and that both annual and quarterly periods are available, but it says nothing about history depth, data freshness/lag, auth or rate limits, or how an invalid ticker is handled.

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 resource and source before the usage cue. The metric list is long but earns its place by previewing the returned fields; there is no 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 simple three-parameter read tool with an output schema, the definition covers what the tool returns, its source, and its periodicity, so the agent need not have return values explained. The remaining gap is the undocumented limit parameter and the unaddressed overlap with us_company_filings.

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%, so the description must compensate. It adds meaning for ticker ('US-listed company... by ticker') and period ('annual or quarterly'), but the limit parameter is never mentioned and the period values are not given as explicit options, leaving one of three parameters fully 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?

States a specific resource (reported financials of a US-listed company), the source (SEC 10-K/10-Q filings), the lookup key (ticker), and enumerates the reported metrics and periodicity. It does not differentiate itself from the sibling us_company_filings, which shares the filing-based domain, so it falls 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 a clear use context ('analysing or comparing US stocks and you need filed numbers') and an implicit exclusion via 'not estimates', which meaningfully narrows the tool's role. It stops short of naming an alternative tool or stating when not to use it, so no explicit sibling routing.

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. It usefully discloses crawl scope (home, contact, about, imprint pages) and implies a read-only extraction, but says nothing about cost, latency, rate limits, or what happens when listed pages do not exist, which matters for a multi-page crawl.

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 extracted payload followed by the use case; every phrase earns its place. Slightly terse on the operational side, but no waste.

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?

An output schema exists, so return values need no explanation, and the extraction scope is well covered. However, with zero schema descriptions the undocumented `max_pages` parameter leaves a real gap an agent must guess at.

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%, so neither `url` nor `max_pages` is documented anywhere. The description's page list gives an indirect hint about crawl breadth, but it never explains what `max_pages` controls (default 5) or what URL formats are accepted, so it does not compensate for the coverage gap.

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 resource (contact details: emails, phones, social profiles, name/address) and the exact sources it draws from (home, contact, about, imprint pages), so an agent knows precisely what comes back. It does not differentiate itself from the sibling read_web_page, which is the closest adjacent tool, so it falls 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?

"Use to find how to reach a business or enrich a lead" gives clear context for when this tool is appropriate. It offers no exclusions or explicit alternative routing (e.g., when to prefer read_web_page), but the positive use case is unambiguous.

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