The Aftermath

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false and openWorldHint=false, so the safety profile is fully covered elsewhere. The description adds the useful behavioral detail of what the payload contains, which matters because there is no output schema, but says nothing about response size or whether feed/podcast data is live or cached.

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 front-loaded sentence with the resource name, canonical domain, and a compact list of returned contents. No filler, no repetition of the title 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 zero-parameter, non-destructive read with no output schema, the description covers what an agent needs: identity of the site and the categories of information returned. The only shortfall is the absence of any cue about when to prefer this over the sibling retrieval tools.

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 tool takes zero parameters, so there is nothing for the description to disambiguate; the baseline for a parameterless tool applies. No misleading parameter hints are present.

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?

"Describes The Aftermath (theaftermath.news)" names a specific verb and resource, and the enumeration (mission, topics, post count, feeds, podcast shows) tells an agent exactly what information this returns. It does not explicitly contrast itself with siblings get_post/latest_news/search_news, but the orientation/metadata role is clear from the enumerated content.

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 when-to-use or when-not-to-use guidance and no mention of alternatives. Usage is only implied: an agent can infer this is the orientation call to make before diving into posts or news, but nothing in the text states 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 declare readOnlyHint, idempotentHint, destructiveHint=false and closed-world, so the safety profile is covered. The description adds a genuinely useful behavioral caveat the annotations cannot convey: bodies over 100,000 characters are truncated, and a note marks the truncation, which matters for an agent relying on full-text fidelity. It does not describe the not-found/error behavior, keeping it out of 5 territory.

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, both front-loaded with the essentials: what is returned first, then the truncation caveat. Nothing is redundant with the title or the 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?

With no output schema, the description usefully sketches the return shape ("metadata and full text") and the truncation limit. The remaining gap is call-edge behavior: an agent cannot tell from the definition what error results from a missing or unknown slug/URL.

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 50% (the url parameter is documented in-schema, slug is not), so the description has to carry additional weight. It establishes that slug and URL are alternatives for lookup, but does not state precedence when both are provided, nor that zero parameters are required – leaving real ambiguity.

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 and resource ("Returns one theaftermath.news post with its metadata and full text") and names the two lookup keys, so it is clearly a single-post fetch rather than the bulk operations in latest_news or search_news. It stops short of naming those siblings explicitly, which is why it doesn't reach 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?

"looked up by slug or by URL" implies the retrieval contexts in which this tool applies, and the contrast with the list/search siblings is inferable from "one post". However, there is no explicit statement of when to prefer this over search_news, nor of what happens when neither or both keys are supplied.

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 readOnly, idempotent and non-destructive, so the safety profile is covered. The description adds real behavioral detail beyond them: results are ordered newest first, and episodes are silently omitted whenever a topic is supplied — a filtering side effect an agent could not predict from 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?

Two sentences, zero filler, with the core behavior front-loaded and the conditional edge case second. Nothing is repeated from 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 two-optional-parameter read-only listing tool with full schema coverage and annotations, this is nearly complete: ordering and the topic/episode interaction are both disclosed. Only the shape of the returned items is unstated, which is minor given the simple, obvious payload.

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, and the description earns an extra point by clarifying that topic matches a tag and, crucially, that supplying it changes the result set by dropping episodes. The limit parameter is left entirely to the schema, which already documents the cap.

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?

"Lists the newest posts on theaftermath.news, newest first" gives a specific verb (lists), a specific resource (posts), and the ordering. It implicitly separates itself from search_news by emphasizing recency rather than querying, though it never names the sibling 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 description implies the browse-latest use case and notes that topic narrows results, but it never states when to prefer this over search_news or get_post. The agent must infer the routing from the words "newest" and "search" alone.

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 the safety profile (readOnly, idempotent, non-destructive, closed-world), so the description adds value mainly via the AND-matching requirement and the relevance scoring by field. Those are genuinely useful behaviors, but it does not say results are ordered by score or describe result size/pagination.

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 short sentences, well front-loaded: the purpose comes first, then the matching and scoring rules. Every clause carries real information, though the run-together site name and compressed scoring notation cost a little readability.

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-parameter search tool with no output schema, the description covers the core matching behavior but leaves out the semantics of `limit`, whether results are ranked, and what fields are returned. An agent can call it correctly for simple queries but must guess at result ordering and page size.

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 33% (only `since` is documented), so the description must compensate; it does explain query matching semantics (words of 3+ letters, field weighting) but says nothing about `limit` or how `since` interacts with scoring. Partial compensation earns a middle score.

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: searches posts on theaftermath.news, and the matching rules make clear it is keyword search rather than browsing. It does not explicitly contrast with the siblings latest_news and get_post, but the search semantics are distinct enough for an agent to tell them apart.

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 all-words-must-match rule implies when this tool fits (narrowing by keywords) versus listing or fetching a single post. However, it never names latest_news or get_post as alternatives or states when-not to use it, so the routing guidance is only implied.

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