What Led To

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

With no annotations, the description carries the full burden and does disclose the return shape plus a genuine behavioral constraint: entry ids are unique within a timeline, not across the site. It does not cover auth needs or rate limits, but for a read-only detail fetch the critical scoping behavior is disclosed.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences, front-loaded with the payload description and closed with the usage trigger and scoping caveat. The first sentence is long due to the field enumeration, but every element listed is meaningful and no sentence is wasted.

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 must describe the return value — and it does so thoroughly, including source quotes and links. Combined with the id-uniqueness caveat, an agent has everything needed to call this 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 coverage is 100%, so baseline is 3, but the description adds meaning beyond the schema: it explains why slug is required alongside id (id uniqueness is per-timeline, not global). That is real semantic value the schema's own 'The timeline the entry sits on' does not fully convey.

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 and then enumerates exactly what 'in full' means: summary, type, parties, sources with outlet, publication date, verbatim quote, relations, and cross-timeline links. That enumeration distinguishes it clearly from search_entries (list-level) and get_timeline (structure-level) 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?

Explicitly states the trigger: use after search_entries or get_timeline has found an entry and you need exact wording and a source URL to cite. It also names the prerequisite for correct invocation (pass the slug the entry came from), leaving nothing to inference.

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

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

No annotations are provided, so the description carries the full burden, and it does substantial work: ordering (newest first), inclusion of sources, the limit/total_entries relationship, and the important retrieval caveat that a party is 'named' only when editors listed it among an entry's parties, not on mere text occurrence. What it doesn't cover, permissions/rate limits or whether the page is ever absent, is minor for what is evidently a read tool.

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 scope, then the sibling routing rule, then the return/limit caveats; every sentence is load-bearing. The first sentence is long and packs several clauses, which costs a little readability but not enough to be waste.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With no output schema, the description takes on the return-value burden and discharges it: entry list, newest-first order, sources, and total_entries vs limit. For a two-parameter read tool this is complete enough to call 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 100%, so both parameters are already documented in the schema (id slug format, limit default 40 and max 200), establishing the baseline of 3. The description reinforces the newest-first semantics and total_entries but adds no syntax or format detail the schema lacks.

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 ('everything the site records about one company, person or regulator') and enumerates the scope: role, co-occurring parties, dated entries with sources. It explicitly contrasts with the sibling search_entries, so an agent can distinguish them without opening either schema.

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 an explicit routing rule: 'Use it instead of search_entries when you want one actor's whole history rather than a keyword match.' That names the alternative and the condition that selects it, which is exactly the when-to-use guidance 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?

With no annotations and no output schema, the description carries the full disclosure burden and does substantial work: it enumerates the response contents, states ordering ('newest first'), and explains the since filter's incremental-refresh use case. It stops short of explicitly confirming read-only semantics or what happens for an unknown slug, but the retrieval nature is unambiguous from 'get' and the content inventory.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences, front-loaded with what the call returns, and the content list is dense but justified because no output schema exists to carry that information. The since sentence is compact and ends with the motivating use case. Slightly list-heavy, but nothing is 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 3-param read tool with no annotations and no output schema, the description covers the response shape and the one non-obvious parameter's intent, which is the information an agent most needs. It lacks explicit read-only confirmation and error behavior for a bad slug, but overall it is complete enough to invoke 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 100%, so slug, limit, and since are all documented in the schema already. The description restates the since semantics with a practical framing ('what changed recently') that mildly reinforces the schema's 'updated_at you last saw' note, but adds no syntax or format detail beyond it, and says nothing about limit or slug. Baseline 3 applies.

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?

Specific verb+resource ('One timeline in full') followed by an explicit inventory of what is returned: TL;DR, dated entries, relations, links, watch-next, open questions. This clearly separates it from get_entry (a single entry) and list_timelines (the index), so an agent can route 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 one concrete usage pattern for the since filter ('what changed recently'), which is genuinely actionable. However, it never states when to prefer this tool over siblings like get_entry or search_entries, nor any preconditions (e.g., needing a valid slug from list_timelines). Usage is implied rather than prescribed.

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

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

No annotations are provided, so the description carries the burden. It discloses the returned field set and the intended workflow, which is useful. However, it says nothing about ordering, pagination/limits, or cost, so behavioral coverage is only 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?

Two sentences, front-loaded with what is returned followed by when to use it. No redundant or filler content.

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 schema is empty and there is no output schema, so explaining the returned fields in the description is necessary and done well. Lacking a note on pagination/ordering is a minor gap for a listing 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?

Zero parameters, so the baseline is 4. The description correctly implies an unfiltered listing of every timeline, which is consistent with the empty 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 (list) and resource (timelines) and enumerates exactly what each record contains (topic, tags, entry count, date range, last update, summary). It also explicitly distinguishes itself from sibling get_timeline by naming it.

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?

Explicitly tells the agent when to use this tool ('Start here to find the slug for get_timeline'), effectively routing between this index-listing tool and the detail-fetching sibling. No ambiguity about ordering.

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

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

No annotations exist, so the description carries the full burden and does well: it discloses match semantics (every keyword must match, and which fields are searched), ranking order (ranked, newest first among equals), and what comes back (entry text and url). It omits auth/permission requirements and any mention of pagination behavior beyond the schema's limit.

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. The primary capability and scope come first, matching semantics second, and the sibling hand-off last — well front-loaded and information-dense.

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 steps up by describing return content (entry text and url) and the ranking order, and the schema covers defaults and limits. Only minor gaps remain, such as whether results paginate or what happens with large result sets.

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 already documents all six parameters in detail, including the keyword-match rule and the browse-by-filter case. The description largely restates that schema content; its only additive element (ranking order) is behavioral rather than parameter-specific, so the baseline 3 applies.

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 ("Find dated entries"), names the scope ("across every timeline"), and enumerates the filter facets. The closing pointer to get_entry cleanly separates this multi-entry search from the single-entry 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?

Gives a real routing rule ("call get_entry for quotes and sources") plus an operational mode ("omit it to browse by filter alone"). It never states when this tool is the wrong choice for other intents (e.g. browsing timelines or parties), so it stops short of full when/when-not guidance.

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

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

With no annotations, the description carries the full burden and does disclose useful behavior: return ordering (oldest first), default window (today to horizon), echoing back param values, and the month-precision matching semantics. It omits what happens when nothing is scheduled, rate limits, or auth, so it's solid but incomplete.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences, front-loaded with the resource and examples, then the usage and return semantics. It's a bit dense, packing several clauses into sentence two, but every element 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?

Given two optional parameters, no output schema, and no annotations, the description is nearly complete: it covers purpose, usage, ordering, default scope, and precision edge cases. Minor gaps (empty-result behavior, pagination) keep it from a 5.

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 meaning beyond the schema by explaining that month-only dates carry precision=month and are matched on the month, and by framing 'today to the horizon' semantics — value the schema doesn't provide.

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 resource ('scheduled dates the timelines are watching') with concrete examples (earnings, rulings, launches, rule deadlines) and contrasts its cross-site scope against reading individual timelines. That cross-cutting scope cleanly distinguishes it from siblings like get_timeline and list_timelines.

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 when-to-use ('to answer what happens next across the site, rather than reading each timeline for its own catalysts'), which implicitly routes the agent away from per-timeline tools. However, it doesn't name a specific sibling alternative or state any explicit exclusion, so it falls short of the 5 bar.

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