smry Product

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

Annotations already declare readOnlyHint=false, destructiveHint=false, and idempotentHint=true. The description adds useful context beyond annotations: it requires authentication, is persistent, and has the ongoing side effect of delivering updates into followed sources. No contradiction with 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 terse sentences with the core action front-loaded and no filler. Every phrase ('persistent', 'page-change', 'followed sources') adds meaning, and there is no repetition of schema details.

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 2-parameter creation tool, the description covers the main effect and product context, and annotations cover safety and idempotency. However, there is no output schema and the description does not say what a successful call returns (e.g., a monitor identifier), and 'followed sources' is left undefined.

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 the description does not mention the optional title parameter at all. 'Web page' only indirectly maps to url, leaving the agent to infer url format and title semantics entirely from the schema. The description does not compensate for the low schema coverage.

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?

Description uses a specific verb ('Create') and names a concrete resource ('persistent page-change monitor') with a clear effect ('delivers future updates into the user's followed sources'). This clearly distinguishes it from read/search siblings like open_web_pages or search_web.

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 signals a clear use case: persistent monitoring of a web page for changes. However, it does not explicitly say when to choose this tool over alternatives such as follow_feeds, nor does it state exclusions or when not to use it.

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 mutating, idempotent, open-world, and non-destructive behavior. The description adds that the action is authenticated and that new entries will appear automatically. It does not mention failure modes, duplicate handling, or side effects, but the idempotent hint mitigates that gap.

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 concise sentence that front-loads the authentication requirement and quickly states the core action and outcome. The phrase 'smry product action' is slightly vague but not wasteful.

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 two parameters and no output schema, the description is incomplete: 'collection' is entirely unexplained, and there is no mention of return behavior or error conditions. The core effect is clear, but an agent would not know how to use the optional parameter 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 0%, so the description carries the burden of explaining parameters. It never mentions 'urls' or 'collection' or what they do, leaving the optional collection parameter especially ambiguous.

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 clearly states the action: 'Add public RSS or Atom feeds to the user's account' so entries appear automatically. This distinguishes follow_feeds from siblings like search_feeds (searching feeds) and save_article (saving individual articles).

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 gives no guidance on when to use follow_feeds versus alternatives such as search_feeds or create_monitor. It implies subscription to existing feeds but does not state exclusions or prerequisites beyond authentication.

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 readOnlyHint and openWorldHint annotations already covering safety, the description adds valuable behavioral context: token-budgeted output, paragraph-anchor addressing, and the exact return shape (outline, requested window, next_cursor). It also promises 'clean, source-grounded text,' setting accurate expectations beyond the 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?

Three sentences, each earning its place: the core capability, the return behavior, and the usage routing to a sibling. The most decision-relevant information is front-loaded, and there is no fluff or repetition of schema details.

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?

The description fully enables an agent to call this tool correctly: it covers the input type, output structure, pagination continuation via next_cursor, and when to choose a different tool. The presence of a rich output schema and full parameter descriptions means nothing essential 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%, and the schema already documents url, cursor, and max_tokens with detailed guidance including defaults and ranges. The description's references to 'token limit' and 'paragraph anchor' reinforce the schema but do not add materially new parameter semantics, so the baseline of 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 ('Fetch') and resource ('clean, source-grounded text for a public article or YouTube URL'), and immediately distinguishes itself from search_article by framing this tool as the whole-text reader. An agent can tell exactly what this tool does and how it differs from the closest sibling.

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 explicitly says 'Prefer search_article when you have a specific question rather than needing the whole text,' giving both a clear when-not-to-use condition and the correct alternative. This leaves no ambiguity about the intended selection between the two reading-oriented 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?

Annotations already declare readOnlyHint, openWorldHint, and destructiveHint, so there is no contradiction. The description adds useful constraints: it works on public pages, accepts up to four at once, and returns clean Markdown rather than raw HTML. This adds behavioral context beyond what the annotations alone provide.

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 with no filler. The core function is front-loaded in the first sentence, and the second sentence gives focused, useful guidance on the optional context parameter.

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?

Rich annotations and an output schema cover safety and return structure, and the description handles the main call shape and the context parameter. The undocumented 'live' and 'start' parameters and the lack of sibling-selection guidance leave real gaps for an agent trying to use every option correctly. Overall it is adequate but not fully 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 description coverage is 0%, so the description carries the burden of explaining parameters. It compensates for 'context' by explaining that it focuses extraction and can be omitted for a direct read, and it reinforces the four-page limit. However, 'live' and 'start' remain unexplained, leaving a partial 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 action ('Open'), a clear resource ('up to four public pages'), and a distinct result ('return clean Markdown evidence'). The scope and output format set it apart from search_web and get_article, though it never names those siblings 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?

The only usage advice is about the context parameter: use it for focused extraction or omit it to read the page directly. There is no guidance for choosing open_web_pages over search_web, get_article, or follow_feeds, so tool selection 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?

Annotations already cover read-only status, destructiveness, and idempotency. The description adds useful context beyond that by noting the action requires authentication and that the URL must be public. It also frames the save as targeting the user's own library.

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 one concise, front-loaded sentence with no filler. It communicates action, authentication, idempotency, and purpose efficiently.

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?

Annotations cover idempotency and non-destructiveness, and the description adds auth and public-URL constraints. However, optional parameter semantics (tags/status) remain unexplained and no routing guidance relative to siblings is present, leaving the definition adequate but not fully 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 description coverage is only 33%, and the description only reinforces the URL parameter's 'public' nature. The optional tags and status parameters are not semantically explained in either the schema or description, so the agent must infer their meaning from names and enums 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?

The description states a clear action: save a public URL to the user's reading library. It adds downstream purposes (reading, search, organization) and mentions idempotency. It does not explicitly differentiate from update_library_item, but the name/title and core action are clear enough.

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 provides no explicit guidance on when to use this tool versus alternatives, such as update_library_item for modifying existing items. 'Authenticated smry product action' gives context but no exclusions or comparison to 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?

Annotations already declare readOnlyHint=true, openWorldHint=true, and destructiveHint=false, so safety is covered. The description adds valuable behavioral context beyond that: it filters to only relevant passages, anchors to paragraphs, labels with sections, and explains token efficiency. No contradictions 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?

Two sentences, no filler. The core behavior is front-loaded, the differentiation from get_article comes second, and every clause adds information. Nothing is redundant with the schema or annotations.

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?

The tool has a rich output schema and fully documented parameters, so the description doesn't need to explain return values. It covers the key decisions an agent must make: when to use it, what it reads, what it returns, and how it differs from the closest sibling. No critical information is missing for a read-only search 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 fully documents url, query, cursor, max_tokens, and max_passages. The description reinforces the purpose of query ('specific question about a link') and hints at URL types, but it doesn't add per-parameter meaning beyond what the schema already 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 ('Read ... and return') and resource ('a public article or YouTube URL'), and defines the output precisely: only relevant passages, each anchored to its paragraph and labelled with its section. It also explicitly distinguishes itself from get_article, so an agent can tell them apart 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?

The description gives an explicit when-to-use rule: 'Use this instead of get_article whenever you have a specific question about a link.' It also names the alternative directly and gives a rationale (token efficiency and citable anchors), leaving no ambiguity about 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?

Annotations already declare readOnlyHint=true and destructiveHint=false, so the description need not restate that. It does add useful context: it mirrors the Discover page's ranking and explicitly says it 'only discovers sources,' which clarifies scope. However, it does not disclose potential edge behaviors (e.g., exact match semantics, language handling) beyond what the schema states, so the incremental transparency is moderate.

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 focused paragraph that front-loads the core purpose, then quickly covers modes, sorting, and the follow_up pointer. Every sentence contributes value; there is no filler, but it could be tighter by merging the mode list into a more compact phrase. Still, it is well-organized and readable.

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 five parameters, an output schema, and annotations covering safety, the description covers the key usage scenarios, mode selection, and the boundary to follow_feeds. The output schema presumably defines the return shape, so no further explanation is needed there. It is complete enough for an agent to call correctly, though it does not discuss rate limits or default limit behavior, which the schema already hints at via limits property.

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 documents every parameter. The description adds minor clarifications (e.g., 'omit query to browse suggested sources' and 'use sort=popular'), but these largely echo the schema text. Per the rubric, baseline 3 applies when the schema carries the load, and the description does not meaningfully exceed it.

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 opens with a specific verb and resource ('search feeds' via a discovery catalog) and immediately distinguishes itself from follow_feeds by stating it only discovers sources. It enumerates concrete use patterns (browse, search by topic, create Google News source, discover by URL), so an agent can tell it apart from siblings like search_web or search_article without inspecting 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?

It clearly explains when to use the tool (for discovery) and explicitly names follow_feeds as the alternative for following results. It also gives contextual cues like using sort=popular for popularity ordering, but it does not enumerate when NOT to use it against other search tools, so an agent might still need to infer that search_article is for articles.

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?

The annotations already cover read-only and open-world behavior. The description adds that search snippets are 'discovery aids' and advises opening pages for citation, subtly indicating the tool returns snippets rather than full content. This is a useful behavioral hint, but it does not disclose rate limits, pagination, or other traits 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?

The description is concise—two sentences—with the primary purpose stated first in the opening clause. It avoids unnecessary detail and is well-structured, fitting the expected format for a tool description.

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 an output schema (not shown) and multiple parameters, the description lacks crucial context: it does not specify the output format, explain parameter semantics, or provide usage scenarios. It leaves the agent to infer how to construct queries and interpret results. The annotations provide safety context but do not fill these 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?

The input schema contains parameters (queries, max_results) with no descriptions, and the tool description does not explain their meaning or usage. The mention of 'up to four focused searches' repeats a schema constraint (maxItems: 4) but does not clarify what a 'focused search' entails or how parameters like site, publishedAfter, or publishedBefore should be used.

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 clearly states the tool's purpose: discovering current public sources via web searches. It specifies the verb 'discover', the resource 'current public sources', and a constraint (up to four searches), making the intent unambiguous even without relying on the tool name.

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 provides no explicit guidance on when to use this tool versus siblings like search_article or search_feeds. It implies general web search but does not differentiate conditions or alternatives. The only usage hint ('open the strongest pages before citing') addresses post-search behavior, not tool 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?

Beyond the annotations, the description discloses that the action requires authentication and enumerates the mutating behaviors (move, tag, mark read, update progress). It aligns with idempotentHint=true and destructiveHint=false, with no contradiction.

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 short and front-loads the auth context, then lists operations in one efficient second sentence. The generic 'Authenticated smry product action' prefix carries minor waste but does not obstruct.

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 five-parameter mutating tool with no output schema, the description gives enough high-level context to attempt a call, but it omits alternative routing, return behavior, and clarifications around read_progress/tags. The schema and annotations fill some gaps, not all.

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?

With 0% schema description coverage, the sentence maps actions to the main parameters: tags, status/move, mark_read, and read_progress. However, it does not explain the required id, the meaning of null read_progress, or tag replacement semantics, leaving meaningful gaps.

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 clear resource ('item in the user's library') and enumerates concrete operations: move, tag, mark read, or update reading progress. This distinguishes it from siblings like save_article, but it does not explicitly name a sibling or exclusion, 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?

No guidance is given on when to call this tool instead of save_article or get_article. 'Authenticated' is the only prerequisite hinted at, and there is no mention of exclusions or alternatives.

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