Cryptowisser News

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

Annotations already declare readOnlyHint=true and openWorldHint=false, so safety and world scope are covered. The description adds the return field set (headline, text, summary, author, date, topics, tags, link), which is useful given there is no output schema, but it says nothing about failure behavior when a slug is ambiguous or not found.

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 compact sentence with the identity of the tool front-loaded, followed by the returned fields and the usage note. The trailing 'Suited to...' clause lightly overlaps the opening clause but still earns its place as routing guidance.

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 single-item getter with no output schema, listing the returned fields plus a usage cue covers what an agent needs to select and call it. Only error/not-found behavior and explicit sibling contrast are absent, which are minor for this tool shape.

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 is already documented as 'The article URL or slug.' The description restates the same URL-or-slug semantics without adding format, matching, or normalization details. Baseline 3 applies when the schema does the work.

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 ('Get one Cryptowisser news article in full by its URL or slug') and enumerates the returned fields. The scope ('one article, in full') implicitly separates it from the list-oriented siblings (latest-news, search-news), though no sibling is named 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?

Gives a clear usage context: 'Suited to questions about a specific Cryptowisser article or link.' That tells the agent when this tool is the right pick versus a news-list tool, but it offers no explicit exclusions or named alternatives.

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 readOnlyHint=true and openWorldHint=false, but the description adds real behavioral detail: the default ordering is featured-stories-first rather than newest-first, the default page size is 5, and the returned fields are enumerated. It stops short of any rate-limit or pagination caveats.

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 source, then layers defaults, ordering, and return shape in a logical order. Slightly long with several illustrative examples, but each sentence carries usable information.

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 describing the return payload (5 articles, each with headline, summary, date, age, link) and the ordering semantics. The only meaningful omission is the category filter, one of five 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 coverage is 100%, so the baseline is 3, but the description adds value beyond the schema by translating intent into parameters ("set by_date to true for strictly newest first", "use from/to for a specific period, e.g. 'news from last week'"). The category parameter is never mentioned in the description, leaving that gap to the schema alone.

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 ("Get the latest crypto news from Cryptowisser") with a clear source. However, it never distinguishes itself from siblings like trending-stories or search-news, so an agent must infer the boundary between "latest" and "trending" or "search" on its own.

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 concrete triggering examples ("What's the latest crypto news?", "news from last week") and explains which parameter selection follows from each intent. It does not state when to prefer search-news or trending-stories instead, so alternatives are left implicit.

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 readOnlyHint=true, so the safety profile is covered. The description adds useful behavioral context ('Names, tickers and common aliases are recognised' and the from/to period behavior), but does not disclose result format, ordering, or pagination behavior. Modest value beyond the annotations.

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 front-loaded sentences with no filler; the entity scope and examples come first, then the temporal hint. Efficient and easy to scan, though the long enumeration of entity types borders on listy 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?

For a read-only, single-required-param query tool with full schema coverage and no output schema, the description supplies the key context (entity flexibility, alias handling, date filtering) an agent needs. Only the return shape/ordering is unaddressed, which is a minor gap given the annotations cover the safety profile.

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 reinforces the entity parameter by noting that names, tickers and aliases are accepted, and hints at from/to usage, but adds no format or syntax detail the schema doesn't already provide (e.g., ISO 8601 is only in 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?

States a specific verb (get) and resource (recent Cryptowisser news about a specific entity), with a rich enumeration of entity types and concrete examples. The entity-centric framing is clear, but the description never names or contrasts with the sibling tools (search-news, latest-news, get-article), so an agent can't fully distinguish its scope from theirs without opening schemas.

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?

Offers one concrete usage hint ('Use from/to for a specific period'), which implies the temporal-filtering use case. However, it gives no guidance on when to pick this over search-news or latest-news, and no exclusions or prerequisites, leaving the core when-to-use decision 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?

Annotations only declare readOnlyHint and openWorldHint, but the description goes much further: case-insensitive partial-word matching, AND semantics across keywords, entity-vs-keyword query branching, newest-first ordering, and no relevance ranking. That is exactly the behavioral context an agent needs to predict result quality.

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 purpose and organized into bullets that each carry distinct, non-redundant information. It is on the longer side for a search tool, but there is little filler to cut.

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 search tool with no output schema, the definition covers matching, ordering and date scoping well. It does not describe the shape of a returned article (fields such as title/url/date) or pagination behavior, which is the remaining gap.

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 already 100%, so the baseline is 3. The description adds real meaning on top: it explains that from/to restrict to a period and reinforces the query parameter's intended shape, going beyond the schema's terse field notes.

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 ("Search Cryptowisser news by keywords") and spells out the matching model, so the agent knows exactly what this does. However, it never names or contrasts with the obvious siblings latest-news, news-about or trending-stories, even though its entity-matching behavior overlaps with news-about.

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?

Strong query-construction guidance: use 1-3 distinctive keywords, avoid full questions, know that extra keywords narrow results, and that there are no synonyms or ranking. It lacks when-to-use/when-not guidance relative to siblings, 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 readOnlyHint=true, so the safety profile is covered. The description adds genuinely useful behavioral context beyond that: a one-week lookback window, the upstream source (Cryptowisser), and the fact that each story bundles its latest articles. It omits ordering/ranking logic and any rate or freshness caveats.

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 no filler, and the core scope ('past week', 'ongoing stories') is front-loaded before the usage 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?

For a one-parameter, no-output-schema read tool, the description conveys what comes back (stories with their latest articles), the time window, and the source. Only the ranking/order of the returned stories is left unstated, which is a minor gap.

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 the single 'limit' parameter is fully documented in the schema (default 5, range 1-10), so the description need not repeat it. The description adds no meaning about whether the limit counts stories versus articles, which is the one ambiguity the schema leaves open.

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 ('Get the biggest ongoing crypto stories of the past week') plus the source and the fact that each story carries its latest articles. That scope distinguishes it from a plain article feed, but it never names the sibling tools it competes with (latest-news, search-news).

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?

'Suited to questions about the big or developing stories in crypto' gives an implied usage context, so an agent can infer this is for trend-level questions rather than single-article lookups. However, there is no explicit when-not guidance and no alternative tool is named, leaving the agent to guess against latest-news and search-news.

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