Deep Noodle AI Atlas

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

Beyond the readOnly, idempotent, and non-destructive annotations, the description reveals meaningful behavior: default fact groups, that output preserves requested ID order, that unknown values stay explicit, and that IDs must resolve to distinct records. This gives the agent a concrete model of what will happen when the tool is called.

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 compact sentences front-load the core operation and then add only high-value behavior: defaults, fields behavior, and unknown-value handling. No sentence 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?

For a tool with no output schema, the description covers invocation details, default fields, the fields parameter, and unknown-value behavior. It does not describe the exact response shape or error cases, but the missing details are minor given the stated defaults and constraints.

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 100% schema coverage, the baseline is 3, and the description earns an extra point by explaining that fields selects fact groups (e.g., pricing), clarifying the default output fields, and noting the ordering and distinctness of ids. These details go beyond the schema's raw type constraints.

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: compare two to four catalog IDs or API identifiers in requested order. This makes the operation distinct from sibling retrieval/search tools like get_model, list_models, and search_atlas.

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 context for the tool's main use and mentions that fields selects facts such as pricing, but it never explicitly states when to choose this tool over get_model or search_atlas, nor does it list exclusions. The usage is implied by the verb and title rather than spelled out.

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 covered. The description adds valuable behavioral context beyond these: it discloses the use of publication timestamps rather than occurrence dates, and explicitly states that backfills can introduce older events. This helps the agent understand the data's temporal semantics. It does not contradict any annotation.

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 composed of five short sentences, each adding substantive value. The core purpose is front-loaded in the first sentence, followed by key differentiators and caveats. There is no redundancy or filler. Every sentence earns its place, making the description efficient and scannable.

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 4 parameters and no output schema, the description covers the essential context: what the tool returns (a feed of records), when to use it, and its limitations. However, it does not describe the response format or pagination behavior, and parameter semantics are under-explained. Given the moderate complexity and lack of output schema, a bit more detail on the return structure would improve completeness, but the description is largely sufficient for correct invocation.

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 must compensate for parameter meaning. However, the description only indirectly references the 'since' parameter ('since a date') and does not explain the format or semantics of any parameter, including limit, offset, or changeKind. The schema provides types and constraints but no descriptive text. The agent must infer parameter meaning from names alone, which is insufficient for a tool with 4 parameters and an enum.

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: a current-record feed of additions and revisions since a date. It specifies the resource (Atlas records) and the action (retrieve changes). It also distinguishes itself from search_atlas by explaining the difference in timestamp semantics and explicitly noting it is not a historical diff or deletion log. This provides strong differentiation from sibling tools.

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 instructs when to use this tool versus search_atlas: 'For what happened recently, use search_atlas with since/until instead.' It also warns that publication backfills can include older events, clarifying a common pitfall. This gives clear guidance on selection and expectations, leaving no ambiguity about when to invoke this tool.

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?

Annotation Contradiction: annotations declare openWorldHint=false (absence is meaningful in a closed world), yet the description states 'empty links can mean unwritten context, not an unconnected event,' telling the agent that absence should not be treated as conclusive. The description does add useful context about hasExplanation/explanationScope/explanationCoverage, but the contradiction with the openWorldHint annotation forces a low score per rubric.

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 dense sentences that front-load the core purpose before the explanation-mode detail. Slight density issue: hasExplanation, explanationScope, and explanationCoverage are introduced as jargon without definition, and the final open-world aside adds interpretive weight.

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 names the returned content categories (facts, sources, date precision, revisions, links, story connections) and explanation fields, which is helpful. However, it leaves the pagination parameters unexplained, offers no routing guidance versus get_events/search_atlas, and the contradictory open-world caveat muddies the completeness contract.

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 25% (only 'include' is documented), so the description must compensate. It reinforces the meaning of include=['explanation'] versus compact facts, but contextLimit and contextOffset are completely unexplained in both schema and description despite being a pagination pair whose semantics are not self-evident. The id parameter is self-explanatory.

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 and resource ('Read ... event facts, sources, date precision, revisions, contextual links and story connections') and distinguishes a single-event read from the plural sibling get_events. The title reinforces the resource. An agent can tell this apart from listing or searching tools 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?

Usage is implied: retrieve one event's compact facts, optionally requesting the full narrative via include=['explanation']. However, there is no explicit guidance on when to prefer get_event over get_events, get_changes, or search_atlas, and no exclusions or prerequisites are 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 declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is clear. The description adds value by disclosing that unknown/unpublished IDs are returned separately (missingIds), that explanations are opt-in, and that pagination is independent for incoming/outgoing context. This goes beyond the annotations, though it could mention more about error handling or response structure.

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) and front-loads the most critical information: the range of events and the missingIds behavior. Every sentence adds value; 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?

Given the tool's complexity (4 parameters, though only one required), the absence of an output schema, and modest annotations, the description covers the main points: what it reads, the count, the missingIds behavior, and note on explanations and pagination. However, it lacks details on contextLimit/contextOffset, which are critical for agents to know they can control pagination, and it doesn't mention that ids are unique or that the order is preserved (it does say 'in request order'). The missingIds and opt-in explanation are well covered.

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 description adds meaning beyond the schema for the 'ids' parameter (it's for published events, and unknown ones become missingIds) and for 'include' (explanation opt-in). However, the 'contextLimit' and 'contextOffset' parameters are not explained in the description at all; the schema only provides numeric bounds, so the description could have clarified their purpose (e.g., for paginating underlying context). With low schema coverage (25%), the description partially compensates but leaves key parameters underspecified.

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 a specific verb ('Read') and resource ('published event details'), and mentions the count range (1-20). It distinguishes itself from the singular 'get_event' by indicating it handles multiple events, though it doesn't explicitly name sibling alternatives or contrast with 'get_event' or 'search_atlas'.

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 this tool (when you need multiple event details from 1 to 20, likely by ID) and mentions that unknown or unpublished IDs are handled via missingIds, which helps set expectations. However, it does not explicitly state when NOT to use it or name alternatives like 'get_event' for a single event, or 'search_atlas' for discovery.

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 flag readOnlyHint and idempotentHint, so the safety profile is covered. The description adds meaningful behavioral detail beyond that: ambiguous or missing lookups return candidate IDs, fields selects fact groups with defaults, and surface disambiguates hosts. The 'sourceRefs resolve through atlas://models/sources' line is cryptic but still goes beyond what annotations 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?

The description is compact and front-loaded with the core read action. Each sentence contributes, but the 'sourceRefs resolve through atlas://models/sources' clause is unexplained and slightly cryptic, making the structure a bit less smooth than it could be.

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 tool with no output schema, it reasonably covers lookup behavior, default fact groups, selectable fields, and ambiguity resolution. A clearer statement of the actual response shape or an explicit pointer to list_models/search_atlas for ID discovery would improve completeness, but the essential calling guidance is present.

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?

Input schema coverage is 100% and the schema already documents the fields array, its defaults, and the surface enum. The description's mentions of defaults and disambiguation largely echo schema text, so it adds minimal new parameter-level 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 opens with a clear verb and resource: 'Read a model by exact catalog ID or unambiguous API identifier.' It further distinguishes this from sibling tools like list_models and search_atlas by emphasizing exact ID lookup and the fallback to candidate IDs for ambiguous or missing lookups.

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 states when to use the tool ('by exact catalog ID or unambiguous API identifier') and explains when the surface parameter is needed ('surface disambiguates hosts'). However, it does not explicitly name alternatives such as list_models or search_atlas or provide when-not-to-use guidance beyond the ID-based focus.

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, and non-destructive behavior. The description adds valuable behavior beyond that: the response is compact by default, paginated, can include a full narrative via include, and availability is signaled by hasExplanation/explanationScope. This is meaningful behavioral context 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 compact and front-loaded: it states the core read behavior first, then the optional include behavior, then the scope exclusion. Each sentence carries information; there is no redundant phrasing or 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?

For a read-only tool with no output schema, the description covers the key call decisions: default output, pagination, the optional explanation mode, and the boundary that subsidiaries/successors are separate. It does not name sibling alternatives or fully specify the response fields, but given the complex sibling set and annotation support, it is reasonably 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?

With schema description coverage at only 25%, the description helps partially: 'paginated events' implies the purpose of limit/offset, and the include behavior is described both in the description and schema. However, the description does not explain the semantics of slug beyond the title, nor does it detail how limit/offset interact with pagination. It adds some value but does not fully 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?

The description states a specific verb and resource ('Read ... organization facts and paginated events'), making the core purpose clear. It does not explicitly distinguish itself from siblings like get_events or get_changes, but naming 'organization' as the subject provides enough differentiation for an agent to recognize the tool's scope.

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 useful contextual guidance: requesting 'explanation' changes the response, and subsidiaries/successors are not included. However, it does not explicitly state when to use this tool instead of a sibling like get_events, and the 'separate' note never names an alternative. Usage is implied rather than precise.

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 non-destructive behavior, so the bar is lower. The description adds some behavioral context by noting that newer research leads use strict phrase matches and are separate from reviewed narrative, but this statement is vague and its practical implications are unclear.

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-loaded with the core read purpose lockstep. The second sentence is concise but cryptic; still, there is no fluff or redundancy, so it remains an efficient definition.

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 read tool with three parameters and no output schema, the description names content areas but fails to explain how to identify a story, how limit/offset behave, or what the response format is. The research-lead note is not actionable, leaving meaningful gaps for an agent trying to invoke the tool 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 must compensate for the undocumented 'slug', 'limit', and 'offset' parameters. It does not explain any of them, nor does it clarify how the research-lead note relates to parameter usage. The agent gets no meaningful parameter semantics from the description.

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 ('Read') and enumerates the content components ('narrative, labeled interpretation, citations, chronology, open questions and Markdown'), which identifies the resource and distinguishes it from list/search siblings. However, it does not explicitly name or contrast sibling tools, so it stops short of full differentiation.

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?

There is no explicit guidance on when to use this tool versus alternatives like list_stories, get_event, or search_atlas. The note about 'newer research leads' is too cryptic to serve as a selection rule, leaving the agent to infer when this tool is appropriate.

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 read-only, idempotent, and non-destructive behavior. The description adds substantial behavioral detail beyond this: default availability filtering, sort ordering, pagination semantics, and nuanced handling of unknown values via matchedUnknown, includeUnknown, undatedMatches, and releaseDateKnown. The warning that 'unknown' is not unsupported, free, or older is especially valuable.

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?

Every sentence earns its place. The core action and scope are front-loaded, and the remaining sentences add distinct, non-redundant behavioral nuances. The density is justified given the tool's complexity.

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 20-parameter tool with no output schema, the description covers defaults, catalog lookup, unknown and undated record semantics, and result-related fields like matchedUnknown and undatedMatches. It falls just short of complete because it does not describe the full record shape or explicitly distinguish when to use get_model/compare_models instead.

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 already documents 70% of 20 parameters, so the baseline is solid. The description adds meaning beyond the schema by explaining cross-cutting semantics like includeUnknown, matchedUnknown, and releaseDateKnown, and by pointing to the catalog for enum values and price units. It does not walk through every parameter, but the most ambiguous behaviors are covered.

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?

Opens with a specific verb and resource: 'Browse compact model facts.' It immediately states the tool's scope and capabilities (search, filters, sorting, pagination), making it clearly distinguishable from detail-oriented siblings like get_model or compare_models.

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 useful context: defaults to current models, newest documented release first, and directs the agent to read atlas://models/catalog for filter values and price units. However, it never explicitly names alternatives or states when list_models should be preferred over get_model or compare_models, so routing is only implied.

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 disclose readOnly, idempotent, and non-destructive behavior. The description adds that only published briefs are returned and that pagination is supported, but it does not disclose output shape, ordering, or API-specific behaviors like auth or rate limits. The added context is moderate but not exceptional.

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 front-loaded sentence with no filler. Every clause contributes information: the action, the scope of briefs, the fields returned, and the pagination behavior.

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 the lack of an output schema and 0% parameter schema coverage, the description gives only a vague sense of the returned fields and pagination mechanics. It is adequate for a simple paginated list, but an agent cannot determine the exact response shape or how limit and offset behave beyond schema defaults, and no sibling routing is provided.

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. The word 'pagination' signals that limit and offset control paging, which adds some meaning beyond the raw schema. However, it does not explain defaults, ranges, or the exact semantics beyond what the schema already shows, and the parameter names are fairly self-explanatory.

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 uses a specific verb, 'Enumerate,' and names a concrete resource, 'published briefs,' while listing the key attributes (review dates, evidence cutoffs, pagination). This clearly distinguishes it as a listing tool versus siblings like get_story (single-item retrieval) or search_atlas (search).

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 an enumeration use case and mentions pagination, giving clear context for when to list briefs. However, it provides no explicit when-to-use or when-not-to-use guidance, nor does it name alternatives such as search_atlas or get_story for comparison.

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 mark it as readOnly, idempotent, and non-destructive, and the description adds rich behavioral context beyond that: match/any semantics, sort=most-linked behavior, pagination metadata per result family, and the specific organizationFacets rule. These are non-obvious behaviors an agent needs to interpret results correctly.

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 dense but efficient, with every sentence adding a distinct behavioral rule. It front-loads the purpose and then packs critical search semantics and pagination details without fluff.

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 carries the burden of explaining return behavior. It does well by describing result families, separate labeling, pagination metadata, and organizationFacets. It could go further by enumerating each result family's fields, but it is complete enough for correct invocation.

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 20%, but the description compensates for key parameters: 'match=all', 'sort=most-linked', 'since/until', and the q-only condition for organization name/evidence matches. It does not explicitly cover limit/offset or category, though those are more inferable from schema constraints.

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: 'Find relevance-ranked events, briefs, and organizations.' This clearly distinguishes the tool from siblings like get_event and get_model by focusing on multi-type search rather than single-entity 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?

It explicitly separates this tool from get_changes: 'For what happened recently, use since/until here; for records published or edited recently, use get_changes.' This gives an agent a concrete decision rule for choosing between the two tools.

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