WarStrikes

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

Annotations already declare readOnlyHint, idempotentHint, non-destructive and closed-world, so the safety profile is covered. The description adds beyond that: date interpretation is strictly UTC, omission defaults to yesterday, and every returned item carries a link to its underlying report — useful behavioral detail about the response shape. It stops short of saying what happens for a date with no coverage or how large the response can get.

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 compact sentence with no filler; the default behavior and the date interpretation are placed early where an agent will see them first.

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 one optional parameter, full schema coverage, and rich annotations, the definition covers what is needed to call it correctly, and it compensates for the missing output schema by describing region grouping and per-item report links. A note on empty/partial coverage for a date or expected volume would close the remaining gap.

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% and the single parameter already documents the YYYY-MM-DD format, so baseline would be 3. The description adds real meaning the schema lacks: the value is interpreted in UTC and omitting it defaults to yesterday, which the schema does not declare as a default.

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 resource (the daily briefing) and clarifies its scope: everything public sources reported on a given UTC date, grouped by region, with each item linked to its report. That contrasts reasonably with the retrieval siblings (get_event, get_report, search_*), though it never explicitly says it is an aggregated digest rather than a 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?

It gives an implicit usage cue by stating the default is yesterday, which tells the agent it can call with no argument for the most recent digest. However, it never states when to prefer this over search_events or search_reports, nor any exclusions or prerequisites, so 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.

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

Annotations already declare readOnly, idempotent, non-destructive and closed-world, so the safety profile is covered. The description adds genuinely new context: an API key plus the Events layer entitlement is required, and the response includes evidence and revision data. It stops short of describing error behavior for a missing key or unknown id.

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 with no filler. The auth prerequisite is front-loaded, which is defensible for a gated tool, though the core purpose statement could arguably come first.

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 one-parameter read tool with rich annotations and no output schema, the definition covers access requirements, the lookup key, and the shape of the returned content. A note on behavior for an invalid id would make it 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 coverage is 0% and the single `id` property is typed only as a string with no description. The phrase "One Event by id" at least confirms the id refers to the Event identifier, which is marginal added meaning over the 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?

"One Event by id, with its evidence and revision" identifies the specific resource (a single Event), the retrieval key (id), and the payload content. It distinguishes itself from siblings like search_events or list_regions by being a single-record lookup, though the verb is implied rather than stated.

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 auth prerequisite (WarStrikes API key with the Events layer) is clear, and "by id" implies this is the follow-up call after finding an id elsewhere. However, it never explicitly says to use search_events to discover ids or when to prefer this over search_events.

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, idempotent, non-destructive behavior, so the description adds value by disclosing the payload: source, precision, nearest infrastructure, and nearby reports. It also flags that only public reports are returned, which is genuine behavioral context the annotations do not carry.

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 that identifies the resource, the identifier source, and the returned fields with no filler. Every clause carries information an agent would otherwise have to guess.

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 one parameter and no output schema, the description covers the key gaps: what the id is and what the response contains. It is slightly thin on failure modes (missing/private reports) but otherwise 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?

Schema coverage is 0%, so the description must compensate, and it does by explaining that the integer id is the number embedded in the warstrikes.com/event/<id>-… URL rather than an arbitrary identifier. That is meaningful guidance beyond the bare 'integer, minimum 1' in the schema, though it omits error behavior for nonexistent ids.

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 resource (a single public report) and scope (lookup by id), which distinguishes it from the list-oriented sibling search_reports. The verb is carried by the name/title rather than the sentence, so it falls just short of a full 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?

The phrase 'One public report by its id' implies single-record retrieval versus the sibling search tools, but it never explicitly says to use search_reports to discover an id or what to do when the id is unknown. Usage is implied rather than 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?

The annotations already declare readOnly, idempotent, non-destructive, and closed-world, so the safety profile is covered. The description adds real value by disclosing the auth requirement (API key plus Signals layer), but it says nothing about behavior for a missing or invalid id.

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, with the auth prerequisite front-loaded. The second sentence is telegraphic to the point of being cryptic, but nothing is padded.

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 one-parameter read tool with annotations and no output schema, the description covers auth and scope. It leaves the id format, the where-to-get-the-id flow, and the error behavior undocumented, which matters when the schema describes nothing.

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 schema only declares `id` as a required string. The description says "by id" but adds no format, source, or example, so the agent gets no help distinguishing a slug from an opaque identifier.

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?

"One Signal by id" states the resource and the cardinality, which implicitly separates it from search_signals. However, it is a fragment without a verb, so an agent must infer that the operation is a single-record fetch.

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 the prerequisite (an API key with the Signals layer) and implies "use when you already have an id." It never names search_signals as the alternative for resolving an id, and it states no exclusions.

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 useful context about the returned data (24h/7d report counts, region page), but it does not state whether pagination applies or how the region page relates to the list. With annotations carrying the safety burden, this adds some value but not rich behavioral detail.

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 sentence with no wasted words, and the core subject is front-loaded. However, it omits key structural elements like a verb and a clear statement of the return format, so brevity comes at the cost of clarity.

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 simplicity (no parameters, no nested objects, no output schema), the description provides enough context to know roughly what data comes back. It remains incomplete regarding the exact response shape, pagination, and whether the region page is a URL or an identifier, which matters for an agent that must use the output.

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?

This tool takes zero parameters, so the baseline of 4 applies. The description does not need to explain parameter syntax, and its mention of what data is returned effectively compensates for 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?

The description names the resource ("conflict regions WarStrikes follows") and hints at the returned data (report counts for 24h/7d and the region page). However, there is no specific verb, and it is unclear whether this lists, counts, or retrieves regions. Siblings like search_events and get_event describe retrieval actions, so the differentiation is only implicit.

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 explicit guidance on when to use this tool versus siblings such as search_events or get_daily_briefing. There is no mention of prerequisites, exclusions, or alternatives. The agent must infer that this is the entry point for discovering available regions.

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 readOnlyHint, idempotentHint, destructiveHint=false and closed-world scope, so the safety profile is covered. The description adds real value with the auth prerequisite ('Requires a WarStrikes API key with the Events layer') — a genuine gating condition not expressible in annotations. Beyond that it discloses nothing about result shape, aggregation across reports, or pagination depth, so it is useful but thin.

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 compact sentences with no filler. Front-loading the auth requirement is defensible since it can block the call entirely, though it displaces the action statement. Slight structural weakness: the reader must reach the second clause to learn what the tool accepts.

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?

Twelve optional filter parameters and no output schema mean the description should carry more weight than it does — particularly around pagination behavior and what a returned event contains beyond the four named facets. The auth prerequisite and domain-model definition partially compensate, but a complex, fully-optional query tool deserves more than endpoint delegation.

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% across all 12 parameters, with examples, enums and formats already documented in the schema. The description adds no parameter-level meaning beyond pointing at the upstream API specification. Per the rubric, full schema coverage sets the baseline at 3.

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 defines the resource well ('one occurrence linked to all the reports that describe it, with precision, entities, sectors and impacts'), which is genuinely useful domain framing. However, it never states the action plainly — it only implies filtering via 'Same filters as GET /api/v1/events' and does not distinguish this from sibling tools like search_reports or get_event. An agent gets the object's nature but not a crisp verb-and-scope statement.

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 when-to-use guidance and no mention of alternatives. With six siblings (get_event, search_reports, search_signals, get_signal, get_daily_briefing, list_regions), the agent is left to infer that this is the bulk/exploratory retrieval path versus get_event's single-record fetch. The only conditional content is an auth prerequisite, not usage 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 readOnly, idempotent, non-destructive and closed-world, so the safety profile is covered. The description adds real context beyond that: the 7-day recency ceiling, newest-first ordering, and the shape of each result (named public source, place, time, source type, location precision), which is valuable given there is no output 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?

A single front-loaded sentence that packs scope, ordering, result fields and filters with no filler. The mid-sentence clause "what a named public source reported, where and when" is slightly convoluted but still parseable on one read.

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?

Because there is no output schema, the description's result-field summary is doing necessary work, but it leaves a discrepancy unexplained: it advertises "last 7 days" while the schema's hours parameter defaults to 24, so an agent may wrongly assume a 7-day default window. The absence of any note on default result count or paging also leaves a gap.

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 two parameters are enums, so the schema already carries parameter meaning; the description only names the word/region/type filters and omits hours and limit. Baseline 3 applies, and the description adds no syntax or matching-behavior detail (e.g., whether query is OR/AND across title, summary and place).

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-scope ("Reports from the last 7 days, newest first") plus the returned fields (source, place, time, source type, location precision), which clearly identifies it as a report search. It does not name the sibling search_events or search_signals, so the distinction between searching reports vs. events vs. signals must be inferred from the word "reports".

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?

"Filter by words, region and type" implies the intended use case of narrowing a recent-reports feed, but there is no explicit when-to-use guidance and no exclusions. Nothing tells an agent when to prefer search_reports over search_events, search_signals, or get_report for a single record.

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, non-destructive, and closed-world, so the safety profile is covered. The description adds the one thing annotations cannot: an auth requirement (API key with the Signals layer). It says nothing about pagination semantics or result characteristics, so the value added beyond structured data is limited to the auth note.

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 with no wasted words, and the auth prerequisite is front-loaded. However, the text is telegraphic rather than well-structured — it defines the domain object before stating the operation, and the fragment "Same filters as GET /api/v1/signals" reads as a note rather than guidance.

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 15 optional filters, no output schema, and no documented return shape, the description should at least say what a result contains or how pagination behaves. It does not address results at all, and it leaves the relationship to get_signal and the sibling search tools unexplained, so an agent must open the schema and guess at the rest.

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 every one of the 15 filters is already documented in the schema, establishing a baseline of 3. The description's only parameter statement, "Same filters as GET /api/v1/signals, plus severity, confidence and materiality," references an external endpoint the agent cannot inspect and adds no meaning beyond what the schema already provides.

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 defines what a Signal is ("WarStrikes assessments of severity, confidence and materiality") and implies a filtered retrieval, but never states the verb explicitly — no "search/list signals matching filters." It also fails to distinguish this tool from siblings search_events, search_reports, or get_signal, leaving the agent to infer that this is the batch search over signals while get_signal fetches one.

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 guidance is a prerequisite ("Requires a WarStrikes API key with the Signals layer"), which is genuinely useful. There is no statement of when to use this instead of search_events or search_reports, nor when to prefer get_signal for a single record.

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