Good Morning Maldives

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 behavioral context beyond that: the output is markdown, it terminates in the canonical URL, and partner content is explicitly labelled rather than presented as GMM journalism — an important trust distinction the annotations cannot convey.

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 output format, then a single sentence carrying the partner-content caveat. No filler and nothing redundant with the schema.

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?

An output schema exists and the parameters are fully documented, so the description only needs to orient the agent — which it does well, including the partner-content labelling. The one gap is sibling routing (why get_article over get_page_markdown or search_articles), which would complete the picture.

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 both parameters (slug, lang) are documented in the schema itself, including the slug's positional meaning and the en/dv enum values. The description adds nothing about either parameter, 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?

The description uses a specific verb+resource combination ('full text of one published article as markdown') and enumerates the payload's parts (headline, byline, key takeaways, references, canonical URL). It implicitly separates itself from get_page_markdown by scoping to 'published article' and from the list/search siblings, but never names an alternative 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?

Usage is only implied: the agent must infer that this is the retrieval step after list_recent_articles or search_articles has produced a slug. There is no explicit when-to-use/when-not guidance and no mention of the many sibling retrieval tools (get_document, get_page_markdown, get_first_light) that could be confused with 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=true, idempotentHint=true and openWorldHint=false, so the safety profile is covered. The description adds genuinely useful behavior beyond that: the response is markdown and terminates in a canonical URL. It does not mention error behavior for an unknown slug or whether lang changes the rendered content.

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 dense sentence with the key fact – this is one document – front-loaded, and no filler. It is a fragment without an explicit verb, which slightly weakens readability but wastes no space.

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 a rich annotation set, full schema coverage and an output schema, the description only needs to frame selection and format. It covers format (markdown, canonical URL) but omits routing guidance against five document-related siblings, leaving a real gap for an agent choosing among them.

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%, with slug documented as 'the last part of its /documents/ URL' and lang as an en/dv enum, so the schema carries the parameter burden. The description adds nothing further about either parameter, which is the baseline expectation when coverage is complete.

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 precisely ('One primary-source document') and enumerates its contents (issuer, reference, dates, GMM summary, file link, news coverage), which separates it from get_article and get_page_markdown. The verb is implicit – it never says 'retrieve/fetch by slug' – but the scope is unambiguous.

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 statement of when to call this versus list_documents, search_documents, or the sibling get_article. The agent must infer from the name and the word 'primary-source' that this is a slug-keyed single-record fetch.

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 that this is a safe, read-only, idempotent operation, so the bar for behavioral disclosure is lower. The description adds meaningful context beyond annotations: it describes the markdown-plus-structured-data response, fact anchors, grades, recordRevision, and that the content is GMM's own graded research rather than company-supplied material.

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 front-loaded with the core purpose and remains dense with useful detail about citations and provenance. Every sentence contributes to understanding the returned content or how to cite it, with 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?

Because an output schema exists, the description need not exhaustively describe return values, and it already covers the key content types and citation semantics. The main missing element is usage guidance relative to sibling tools, but the description is otherwise complete for a read-only entity lookup.

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 schema documents both slug and lang, including the enum for lang. The description adds no parameter-specific meaning beyond what the schema already provides, so the baseline score of 3 fits.

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 and scope: one entity's researched record, returned as a markdown dossier plus structured data. It is clearly a single-entity retrieval tool rather than a list/search tool, though it does not explicitly distinguish itself from sibling tools like get_document or get_page_markdown.

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 explains what the tool returns but gives no explicit guidance on when to use it versus alternatives such as get_page_markdown, get_document, or search_entities. The reader can infer it is for fetching a known entity by slug, but the routing guidance is absent.

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 incremental value here is the published-only visibility rule, which tells the agent that some valid-looking dates may legitimately return nothing. The return format note adds modest context but does not discuss errors or what happens for unpublished dates.

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 tight sentences, front-loaded with what the tool returns, then the default behavior, then the availability caveat. Minor redundancy between 'Omit date for the latest published edition' and the schema's identical default 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?

With an output schema present, return values needn't be spelled out, and annotations carry the safety profile. The description covers format, default behavior, and the published-only constraint, leaving only minor gaps like error behavior for unpublished dates.

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 both parameters are fully described there (date format/default, lang enum). The description only restates the date default and says nothing about the lang parameter, so it adds little beyond the schema — 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+resource: retrieves one edition of the First Light morning brief, and even characterizes the return shape (markdown with key number and numbered snippets with links). It implicitly separates itself from list_first_light ('one edition' vs a list) but never names the sibling, so the differentiation is left to inference.

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?

'Omit date for the latest published edition' gives clear invocation context for the default case, and 'Only editions already released to readers are available' sets a real availability boundary. It stops short of naming alternatives such as list_first_light for browsing editions or get_article for individual items.

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. Description adds that output is markdown matching the .md-suffixed site, that every page ends with its canonical URL, and that out-of-set paths are refused with a message. These are useful behaviors beyond 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?

Single paragraph, front-loaded with purpose, then usage, path list, and behavioral notes. No redundant or filler sentences; every part contributes to correct invocation.

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 a generic reader with full schema coverage, rich annotations, and an output schema, the description covers purpose, valid inputs, output hint (canonical URL), and error behavior. Sufficient for an agent to call it 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 the schema documents path and lang. The description adds value by enumerating the accepted path patterns and clarifying that paths outside the set are refused, which goes beyond the schema's single example.

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 (reads) and resource (any public GMM page as clean markdown), and the .md equivalence clarifies output. However, it does not explicitly name or contrast with sibling tools like get_article or get_entity_record, so sibling differentiation is implicit at best.

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 a clear use case: follow a link from another result. Lists valid path patterns, which implicitly defines scope. No explicit when-not or alternatives to typed getters, but the context is clear.

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, destructiveHint=false and openWorldHint=false, so the safety profile is covered. The description adds genuinely non-structured context: the response is markdown and terminates in the project's canonical URL. It stops short of noting response size, latency, or behavior for an unknown slug.

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?

Single sentence, front-loaded with the resource identity and no filler. However it is a verbless noun phrase with a long colon-delimited field list, which is dense to scan and slightly harder to parse than a short declarative.

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?

An output schema exists, so the description need not explain return values, and parameters are fully specified in-schema. The description supplies the markdown format and canonical-URL ending, which is enough for correct invocation of a simple two-parameter read 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 coverage is 100% and both parameters are documented in-schema (slug as the last path segment of /projects/, lang enumerated with a default), so the schema carries the load. The description adds nothing about parameters, so 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?

The description names the resource precisely ('One tracked project') and enumerates the payload contents (parties, value, financing, status against schedule, variations, documents, coverage), which distinguishes it from a search/list tool. What it lacks is an explicit verb and any naming of siblings such as list_projects or get_entity_record, so differentiation is inferred 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?

Usage is only implied: the word 'One' signals a single-project retrieval versus the list_projects sibling. There is no explicit statement of when to prefer this over search_entities or get_document, and no prerequisite or exclusion 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?

Annotations already cover the read-only, idempotent, non-destructive, closed-world safety profile. The description adds useful behavioral context by stating that it returns revision versions and latest observations, and that it reports plainly if the tracker database is unavailable.

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 tightly written sentences with no filler. It front-loads the resource and returned data, then adds the database-unavailable behavior, so every sentence 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 full parameter schema coverage, a present output schema, and complete read-only annotations, the description supplies everything needed for correct invocation. It also covers the notable edge case of the tracker database being unavailable.

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 id and points parameters are already fully documented in the schema. The description does not add meaning beyond the schema, such as how points interacts with revisions or observation ordering, so the baseline score of 3 is appropriate.

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 identifies the resource as a single economy tracker series and enumerates the data it contains: unit, frequency, source, revisions, and latest observations. The singular 'One economy tracker series' implicitly distinguishes it from list_tracker_series, but it does not explicitly name or contrast with that 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?

Usage is implied by the singular resource and the required id parameter, which comes from list_tracker_series, but the description never states when to use this tool versus list_tracker_series or other retrieval tools. There are no explicit exclusions or prerequisites.

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, closed-world behavior. The description adds useful non-annotation behavior: ordering is newest first, company documents are excluded, and pagination is explained in detail including nextCursor presence/absence and how to continue.

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 definition is front-loaded with scope and ordering, then gives only the necessary exclusion and pagination details. Every sentence carries operational value, and the continuation instruction is clear without unnecessary repetition.

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 paginated list tool with full schema coverage, annotations, and an output schema, the description is complete enough to call correctly. It covers scope, ordering, exclusion, and pagination behavior, leaving return-value details to the output schema.

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 lang, limit, and cursor are already documented in the schema. The description reiterates cursor continuation but does not add meaning beyond the schema for any parameter, which fits the baseline of 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 specifies the resource and scope: the independent source library, ordered newest first, excluding company-supplied documents. It is clear enough to distinguish this from a general document search, but it does not name the sibling tools an agent should use for company documents or targeted 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?

It implies this is the browsing/list tool for the independent source library and explicitly excludes company-supplied documents. However, it does not name an alternative such as search_documents for those excluded documents, so routing guidance is only partial.

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 read-only, idempotent, non-destructive behavior, yet the description still adds real value: records carry a canonical URL and a graded-dossier flag, and pagination is described mechanically (nextCursor present only when more results remain, same args plus cursor to continue). That is precisely the kind of operational detail annotations cannot convey.

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?

Single dense paragraph, front-loaded with what the tool returns before the pagination instructions. Every sentence carries information, though the pagination sentence is long and could be split for scanning.

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 paginated list tool with full schema coverage and an output schema, nothing essential is missing: filtering, record shape, and continuation protocol are all covered. It goes beyond the minimum without padding.

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 the value source for the type/category filter (list_entity_categories holds the slugs) and the cursor continuation rule. Minor gap: it calls it a 'category slug' while the parameter is named 'type', which could briefly confuse an agent.

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 (GMM entity records, grouped by category) with a clear list semantics and an optional narrowing filter. It also distinguishes itself from list_entity_categories by pointing there for slugs, so an agent can tell the two apart 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 clear routing context: use list_entity_categories to obtain slugs before filtering here, and use cursor-based re-invocation to page. It does not explicitly contrast with search_entities, so the when-not-to-use case is left implicit.

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, so the safety profile is covered. The description adds genuine context beyond that: what each returned entry contains (slug + record count) and the role of the slug as the value for `type` elsewhere. It does not mention language alternation of the returned labels, but the enum covers that.

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 load-bearing: the first defines the payload, the second supplies the routing guidance. The purpose is front-loaded and there is no filler or repetition of the tool title.

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?

An output schema exists, so return structure need not be spelled out, and the description still conveys what an entry means and how to use it downstream. For a zero-required-parameter, read-only lookup tool this covers everything an agent needs to decide and 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% and the single `lang` parameter already documents `en` vs `dv` with an enum and a default. The description says nothing about language selection, so it adds no meaning beyond the schema, matching the baseline.

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 (entity categories) and its content (slug plus record counts), and names the concrete examples of categories. It also distinguishes itself from list_entities/search_entities by explaining that this is the lookup tool that feeds their `type` argument.

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 says to "read this first when you want to narrow a search" and names the sibling tools that consume its slugs, which is a strong when-to-use signal. It stops short of stating when not to call it (e.g. when you already know the slug), so it is clear context without full 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?

Adds real behavioral detail beyond the annotations: ordering (newest first), the exact fields returned, and pagination mechanics including that nextCursor is absent on the last page and how to continue the walk. Annotations already cover read-only/idempotent safety, so this is the right layer to add value on; it stops short of saying what the cursor encodes or whether new editions can appear mid-walk.

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 sentences, front-loaded with what the tool returns before the pagination instructions. Every sentence carries information: no filler, no repetition of the title.

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, zero-required paginated list tool with annotations and an output schema, the description covers scope, ordering, returned fields, and the full pagination loop. Nothing needed to call it correctly is missing.

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 every parameter (lang, limit, cursor) is documented with defaults and bounds, so the schema already carries parameter semantics. The description only restates the cursor mechanics ('same arguments and cursor set to that value') without adding anything new, so 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+resource: returns the archive of published First Light morning briefs, newest first, with the fields returned (date, title, snippet count). Sibling get_first_light is a single-edition fetch, and 'list_' + 'archive of published editions' distinguishes this enumeration tool from that 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?

Usage is implied by 'archive of published First Light morning briefs', but there is no explicit when-to-use guidance, no exclusion of related siblings like get_first_light or search_articles, and no prerequisites. An agent can infer this is for browsing editions but is not told when to prefer it over alternatives.

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 read-only, non-destructive, idempotent behavior. The description adds useful behavioral context about the returned fields and cursor pagination, including that nextCursor is absent on the last page.

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 and mostly front-loaded, with pagination instructions clearly separated. Minor redundancy exists between the schema's cursor description and the description's cursor explanation.

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 output schema, rich annotations, and full parameter coverage, the description provides enough context to call the tool correctly. The main remaining gap is explicit comparison with sibling 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?

Schema coverage is 100%, so the parameter descriptions already carry the main semantics. The description adds some context around dashboards and pagination but does not add much beyond 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?

The description clearly identifies the resource as GMM chart indicators and specifies what each result contains. It does not explicitly differentiate this tool from sibling listing/search tools, so it stops short of a 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?

Usage is implied: list indicators, optionally filtered by dashboard, with pagination instructions. There is no explicit guidance on when to use this tool versus sibling tools such as list_tracker_series or search_articles.

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, so the bar is lower. The description adds real value beyond them: result ordering, the fact that only public projects are returned, and how pagination signals end-of-results via an absent nextCursor.

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 sentences, front-loaded with what the tool returns, then filtering, then pagination mechanics. No filler; each sentence carries operational information.

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, fully schema-covered list tool with an output schema, this is complete: scope, ordering, filter and the cursor loop are all covered, and return-value shape is left to the output schema as intended.

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% with per-parameter descriptions, so the schema already documents lang, limit, cursor and status. The description adds the constraint that only one status may be supplied and reinforces that continuation must reuse the same arguments, which goes slightly beyond the schema text.

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), resource (public GMM-tracked projects), the fields returned (status, value, employer, contractor) and the ordering (newest first). An agent can distinguish this listing tool from single-item get_project and from the other list_* siblings without opening a 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?

Explains when to use the status filter (optionally one status, with example values) and precisely how to page (re-call with same arguments plus nextCursor). It gives clear context but does not name alternatives such as get_project or a search tool for narrow lookups.

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 correctly spends its budget elsewhere. It adds genuinely non-obvious behavior: partner content is excluded from results, and the continuation mechanism is cursor-based with an absent-cursor terminal condition. Deduction only because rate limits, ordering guarantees, or tie-breaking behavior are not 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?

Three sentences, purpose front-loaded, then the exclusion, then pagination — a sensible order with no filler. Minor waste: the cursor continuation instruction restates what the schema's cursor description already says, so the final sentence is partly redundant with structured data.

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?

An output schema exists and all four parameters are documented, so return shape needn't be explained — and it isn't, correctly. For a simple read-only list tool the remaining gaps (ordering guarantee, whether lang changes section slugs, how empty results look) are minor rather than blocking.

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%, including a clear cursor description and the enum for lang, so the schema carries the load and baseline 3 applies. The description adds a little by glossing section as "desk (section slug)" and by noting partner exclusion, but it says nothing about lang or the limit ceiling that the schema does not already say better.

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?

Names the exact resource and scope: "newest published GMM news articles, optionally from one desk (section slug)" plus the exclusion of partner content. That is enough to distinguish it from search_articles-style siblings, though it never names the alternative explicitly. Only the missing imperative verb keeps it from a 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?

Gives concrete operational guidance for the pagination loop: read nextCursor, call again with the same arguments and cursor set to it, and it is absent on the last page. What it never states is when to pick this over search_articles (keyword query) or get_article (single item), so the when-to-use-vs-alternatives bar is unmet.

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, so the bar is lower, yet the description still adds real value: it discloses pagination semantics (nextCursor present only when more results remain), how to resume, and graceful degradation when the tracker database is unavailable. That is behavior an agent could not infer from the structured fields.

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-loads what the catalogue is before pagination mechanics; every sentence carries information. The cursor instruction is slightly verbose for something the schema also states, keeping it just under top marks.

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 an output schema present, return-value detail is unnecessary, and the description still covers content shape, next-step routing, pagination and failure mode. Nothing an agent needs to invoke or continue correctly is missing.

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 limit, theme and cursor are already documented including enum-like theme values. The description restates the cursor continuation contract but adds no format or constraint detail beyond the schema, which is the expected baseline case.

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 (MMA statistical series catalogue grouped by theme) with what each entry contains (latest figure, year-on-year change) and explicitly separates it from the retrieval sibling get_tracker_series. An agent can distinguish it from list_indicators or search tools without opening the 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?

Explicitly routes the agent onward: 'Open one with get_tracker_series', which names the alternative and the condition that selects it. It does not cover when to prefer other listing tools (e.g. list_indicators), 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?

Annotations already cover the safety profile (readOnly, idempotent, non-destructive, closed-world), and the description adds substantive behavior beyond them: whole-word-prefix matching, accent sensitivity with a concrete counterexample, ordering ('newest first'), and result provenance ('canonical URL to cite'). Pagination mechanics are disclosed precisely, including that nextCursor is absent on the last page.

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 purpose and scope, then matching semantics, then the sibling routing rule, then pagination. Every sentence carries operational information; even the accent example ('Male' does not find 'Malé') is a compact, high-value warning rather than 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 7-parameter search tool with a full output schema, the description covers everything an agent needs to call it correctly: scope, matching rules, ordering, pagination continuation, and where to go when results are empty. Return-value details are correctly left to the output schema, with only the citation-relevant field called out.

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 the baseline is 3, but the description adds real semantics on top: it clarifies the matching rules for q and explains cursor continuation ('same arguments, limit may differ'), which reinforces the schema's caveat. It does not restate the date-range or section-slug meaning beyond the schema, keeping it at 4 rather than 5.

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 ('Full-text search of published GMM news articles'), names the searched fields (title, summary, body), and immediately scopes what is excluded (partner content). It also explicitly separates itself from search_site, so an agent can pick between the two without opening a 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 search_site for a forgiving search or when coverage of First Light, entity records, projects, documents and tracker pages is needed. It also notes partner content is excluded, so the agent knows a null result may mean 'out of scope' rather than 'nonexistent'.

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, so safety is covered; the description adds genuinely non-obvious traits: substring matching semantics, accent sensitivity, and the nextCursor-absent-on-last-page pagination contract. Only the result payload shape is unexplained, and an output schema exists to cover that.

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 purpose, then routing, then matching caveats, then pagination — a sensible priority order. Dense but every clause carries information; the pagination sentence is slightly long but justified by the ambiguity it prevents.

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 search with a full schema and an output schema, all the agent needs is here: what is searched, how matching works, how to get the next page, and which sibling to use instead. Nothing material is missing.

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; the description earns extra by explaining cursor reuse rules (same arguments, cursor unchanged, limit may differ) and by describing what q is matched against rather than just 'words or a reference number'. No added detail for lang or limit beyond 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?

Specific verb+resource with the searchable corpus enumerated (laws, budgets, contracts, reports) and the fields searched (title, summary, reference). It also explicitly contrasts with search_site, so an agent can distinguish it from the nearest sibling without inspecting 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?

Names the follow-up tool (get_document) to open a match and names the alternative (search_site) with the exact condition that selects it — accent folding and searching every kind at once. Continue-vs-freshpage behavior is also spelled out with the cursor mechanics.

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 read-only, idempotent, non-destructive behavior, and the description adds matching semantics that the annotations cannot convey: a substring match where accents count ("Male" misses "Malé"). It also discloses pagination behavior end to end, including when nextCursor is absent and the exact procedure for continuing.

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 front-loaded with what the tool searches, then routing, then matching caveats, then pagination, and no sentence repeats another. The telegraphic style ("Filter by type slug.") fits dense reference prose rather than 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 5-parameter search tool with an output schema, everything an agent needs is present: scope, alternative routes, filter source, match gotchas, and full pagination protocol. Return-value shape is left to the output schema, which is correct.

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 the baseline is 3. The description adds real value beyond the schema by cross-referencing list_entity_categories for valid type slugs and spelling out cursor continuation rules, while the 'q' matching semantics are covered in the prose rather than in 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?

The description opens with a specific verb and resource ("Searches GMM's researched entity records") and enumerates the covered kinds (people, companies, institutions, places). It also distinguishes itself from the sibling tool get_entity_record, which retrieves a single record.

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?

This tool explicitly names two alternatives and the conditions that select them: get_entity_record to open a match, and search_site when you need accent folding across every kind at once. It also names filter-by-type and the list_entity_categories tool that has the slugs in use.

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?

Beyond the read-only/idempotent annotations, it discloses concrete behavior: case- and accent-insensitive matching with an example ("Male" finds "Malé"), slash-wrapped regex syntax, coverage boundaries (most recent 400 stories, 45 First Light editions, all reference records), and that every hit carries a citable canonical URL. It also explains pagination mechanics that annotations cannot express.

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 broad-search positioning and decision rule before mechanics, and nearly every sentence carries information. It is on the long side for a single paragraph, with the coverage limits and pagination details stacked at the end, but nothing is redundant 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?

Even though an output schema exists, the description still supplies what an agent needs to interpret it: nextCursor presence/absence, how to resume, and the fact that results are per-kind buckets. Coverage limits also set correct expectations about result completeness.

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%, but the description adds real meaning: q accepts accent-insensitive terms or /regex/, and cursor must be combined with identical arguments except limit. The non-obvious detail that the cursor advances every kind together and each page returns the next `limit` hits of each kind goes beyond the per-parameter schema text.

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 (searches) and scope (the whole publication) and enumerates the kinds of hits returned: news articles, First Light items, entity records, projects, source documents, tracker pages. It explicitly positions itself as the broad counterpart to search_articles and the other per-kind tools, so an agent can distinguish it from siblings without opening any 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 a direct decision rule: prefer this when the question is not already about one kind of thing, because per-kind tools look only in their own kind. That names the alternatives and the condition that selects them, 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.