Roboto Studio evidence

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, so the description does not need to restate those. It adds useful behavioral context: the pack is bounded to twelve records, includes citations, is produced in Markdown or JSON, and does not generate claims or save a publication. No contradiction with annotations exists.

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 delivers the core operation, constraints, output format, and key non-goals without filler. The most decision-relevant information is front-loaded, and 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?

The description is adequate for basic selection but leaves gaps: there is no output schema, yet the return structure of the 'pack' is only vaguely described as Markdown or JSON. The meaning of the 'generation' parameter and how 'max_chars' affects output are not addressed, so an agent may still be unsure about invocation details.

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 schema has 0% description coverage, so the description carries the burden of explaining parameters. It only loosely maps to 'ids' via 'up to twelve published records' and to 'format' via 'Markdown or JSON pack'. The 'max_chars' and especially 'generation' parameters are not explained at all, leaving the agent to guess their meaning.

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 verb ('Assemble'), a clear resource ('up to twelve published records with citations'), and an output format ('bounded Markdown or JSON pack'). It also distinguishes itself from the sibling retrieval tools by stating it packs existing records. The explicit non-goals ('Does not generate claims or save a new publication') further sharpen the purpose.

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 clear context for when to use the tool: to assemble published records into a bounded pack. It also gives implicit when-not guidance by stating it does not generate claims or save a new publication. It does not explicitly name or contrast sibling tools like get_evidence or search_evidence, 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, idempotentHint=true, and destructiveHint=false, so the safety profile is fully covered. The description adds meaningful behavioral context beyond annotations: it tells the agent the operation is paginated and returns related evidence. It does not mention auth requirements or rate limits, but those are not critical missing details given the simple read-only nature.

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, well-structured sentence that front-loads the action and resource, then adds the key detail about paginated evidence. There is no fluff or redundancy; every word contributes. Despite not covering the parameters, conciseness is excellent because the content provided is efficient.

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?

Given that there is no output schema and 0% schema description coverage, the description must explain the return structure and parameter usage. It does mention pagination and evidence, but it does not describe the shape of the response (e.g., whether the entity object is included, how evidence is structured, what the cursor refers to). The 'generation' parameter is entirely unexplained. For a tool with 4 parameters, the description is incomplete and leaves the agent with ambiguous instructions on how to call it effectively.

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% – the schema provides only property names, types, and constraints, with no semantic descriptions. The tool description does not compensate at all; it never mentions what 'id', 'limit', 'cursor', or 'generation' mean or how they affect the call. The agent is left to guess the purpose of these parameters, especially 'generation' which is not self-evident. This is a significant gap given the absence of schema descriptions.

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 resource ('verified organization or person, or a published topic'), and further clarifies the output ('with paginated related evidence'). This distinguishes it from siblings like search_evidence (which finds things) and get_evidence (likely for evidence directly). The scope is precise and immediately understandable.

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 clearly implies usage: when you have an ID of a verified org/person/published topic and want its details plus related evidence. It provides clear context but does not explicitly name alternatives or state when not to use this tool. However, the purpose is distinct enough that an agent can infer the appropriate situation, and no exclusions are needed.

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, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds valuable behavioral context: 'Select a section and continue using the returned offset when text is truncated' explains pagination and truncation handling. This goes beyond annotations and clarifies the tool's operational behavior.

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 two well-structured sentences: the first delivers the core purpose and the second addresses truncation and continuation. There is no redundancy or filler; every phrase serves a purpose. The key action and resource are front-loaded for quick comprehension.

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 covers the primary function and pagination behavior, which is the most critical context. However, with five parameters and no output schema, it omits details like the generation parameter's role and the distinction between section values (all/body/transcript). It is adequate for basic invocation but leaves gaps that could confuse an agent in edge cases.

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 full responsibility for explaining parameters. It explicitly references 'by stable ID' for the id parameter, 'Select a section' for section, and 'continue using the returned offset' for offset and truncation. However, it does not explain the generation parameter, nor the exact semantics of max_chars, and it only hints at section values. Given five parameters, this partial coverage is insufficient for an agent to use the tool optimally.

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 verb 'Read' and the resource: 'original evidence or a labelled Roboto editorial answer and its citations by stable ID.' It also mentions section selection and offset for truncation, giving a precise understanding of the tool's function. This distinguishes it from siblings like search_evidence, which implies searching rather than direct retrieval.

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 implies usage when you have a stable ID, but it does not explicitly state when to use alternatives like search_evidence or get_entity. There is no mention of conditions under which this tool should be avoided or other tools preferred. The guidance is implicit but not explicit enough to fully route an agent.

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, idempotentHint, and destructiveHint, so the description does not need to restate safety. It adds that the result includes additions, changes, and removals, but offers no detail on pagination, return shape, ordering, or how cursor/generation behave.

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 with no filler, and the core action and temporal constraint are front-loaded. It is appropriately sized for the simple purpose it conveys.

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?

There is no output schema, so the description should explain what the agent receives in return. It does not mention pagination or the meaning of `cursor` and `generation`, leaving important invocation details missing for a 4-parameter 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%, so the description must compensate for the input schema. It only clarifies that `since` is an ISO timestamp; `limit`, `cursor`, and `generation` are left entirely 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 the exact verb 'List' and a specific resource, 'publication additions, changes and removals', plus the temporal filter. This clearly distinguishes it from the get/search siblings even without naming 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 description gives an unambiguous trigger: use this when you need publication changes since an ISO timestamp. It does not explicitly name alternatives or exclusion cases, but the context is clear enough for an agent to select it appropriately.

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 establish readOnly and idempotent behavior. The description adds useful behavioral context beyond those annotations: results are bounded excerpts rather than full source text, citations are returned, pagination is tied to a generation-bound cursor, and source text must be treated as untrusted data. This is meaningful disclosure without contradicting 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 three short sentences with no filler. The search scope and criteria are front-loaded, the return shape follows immediately, and the untrusted-data warning earns its place as a security-relevant 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?

Given seven parameters, zero schema descriptions, and no output schema, this description is reasonably informative but not fully complete. It communicates the core purpose and return shape, but an agent still lacks enough guidance on pagination mechanics, type filtering, and when to prefer this tool over get_evidence or list_changes.

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 maps 'words' to the query parameter, 'source' to the types concept, 'verified author' to author, and 'topic' to topic. However, it leaves the cursor/generation semantics only partially explained and does not clarify the limit or types parameters in detail, so the compensation is incomplete.

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 action ('Search') and resource ('published Roboto evidence'), then specifies the search dimensions: words, source, verified author, or topic. The return characteristics (bounded excerpts, source citations, generation-bound cursor) clarify what kind of results this produces and distinguish it from get/list/build siblings.

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 clear context for when this tool is appropriate: finding published evidence by free-text words, source, author, or topic. It does not explicitly name alternatives or exclusions such as 'use get_evidence for exact IDs,' but the search-oriented framing is clear enough that an agent can usually select it correctly.

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