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

With no annotations present, the description carries the full disclosure burden and steps up: it says results are exhaustive ('every'), that each item includes its description and links, and that it should 'Answer in the user's language.' This adds real behavioral context beyond the schema; it doesn't cover failure modes, but those are minor for a zero-parameter listing tool.

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

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

Purpose is front-loaded in the first sentence, followed by usage triggers and behavioral notes in a logical order. The trailing 'Examples: list_available_resources()' line is mildly redundant for a zero-argument call, but the overall structure is tight with no wasted sentences.

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, low-complexity tool with an output schema already present, the description covers everything needed to select and invoke it correctly: scope, when to use it, output contents, and response language. Nothing an agent needs 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?

The tool has zero parameters, so the baseline is 4; there is nothing for the description to clarify beyond the empty schema. The description sensibly focuses on output behavior rather than inventing parameter guidance.

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: 'List every complementary resource this server offers,' enumerating exact content types (documents, publications PDF, reference datasets, external visualizers). The scope is clearly distinct from all 18 siblings, which are IATI data-querying tools.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly says 'Use this tool whenever the user asks which resources, documents, publications, books or visualizers exist or are available,' with concrete example queries like 'is there a data visualizer for X?'. It lacks an explicit when-not-to-use or named alternative, but the positive triggers are specific enough that selection ambiguity is minimal.

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

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

With no annotations, the description carries the burden of behavioral disclosure. It clarifies semantic nuances, such as reporting organisation not necessarily being the funder and expenditure not being a synonym for disbursement, which helps avoid misinterpretation. However, it does not disclose error behavior, missing-activity handling, or data freshness, leaving notable gaps for an unannotated tool.

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

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

The core purpose is front-loaded in the first sentence, and the glossary is organized by relevant IATI terms. The description is longer than strictly necessary, but each term supports correct use of the tool, especially around transaction types and financial terminology, so the length is mostly justified.

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

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

The description provides enough domain context for a one-parameter tool: it explains key IATI concepts, gives an identifier example, and mentions that the identifier comes from search_activities. The output schema exists and likely documents return values, so the description does not need to restate them. Minor gaps around edge cases like missing activities prevent a higher score.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The schema provides only the parameter name and type with 0% description coverage, but the description compensates well by giving a concrete example ('XI-IATI-IADB-BR-L1231') and explaining how to obtain the identifier via search_activities. This adds meaningful usage context beyond the bare 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 uses a specific verb 'Return' and names the exact resource (IATI activity) and fields (title, status, reporting organisation, totals per transaction type). This clearly differentiates it from sibling tools like activity_transactions or transaction_totals_by_year, which target different data granularity.

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 tool is for retrieving a summary of a single IATI activity and states that the identifier is obtained via search_activities. However, it does not explicitly say when to choose this tool over alternatives such as activity_transactions or transaction_totals_by_year, so usage guidance remains implied rather than explicit.

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

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

No annotations are provided, so the description carries the full burden. It usefully discloses chronological ordering and the included transaction fields, and 'List' implies a read-only operation. However, it does not address error behavior, pagination beyond the limit parameter, authentication requirements, or what happens when an invalid iati_identifier is supplied.

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 its purpose and follows a clear Args/Returns structure. The 'Relevant IATI terms' section is useful domain context but somewhat lengthy; not every definition is strictly required to invoke the tool correctly.

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

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

For a simple two-parameter list operation with an output schema, the description covers the tool's purpose, parameters, return ordering, included fields, and relevant domain terminology. Minor gaps include explicit alternative routing and edge-case or error behaviour, but these are not critical at this complexity.

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%, but the description fully documents both parameters: iati_identifier is described as the IATI identifier of the activity, and limit is described as the maximum number of transactions to return with its default of 50. The glossary also reinforces the meaning of an IATI 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?

The description opens with 'List the transactions associated with an IATI activity', which is a specific verb plus resource. It further specifies what the returned transactions include (type, value, currency, published description), clearly distinguishing it from sibling aggregation tools like mcp_iati_transaction_totals_by_year.

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 use case is implied: this tool returns individual transactions in chronological order, while sibling tools compute transaction totals by year, organisation, sector, or country. However, there is no explicit statement of when to choose this tool over alternatives or any exclusions, so the agent must infer the distinction.

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

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

No annotations are present, so the description carries the full burden. It discloses that the result reports the earliest and latest valid date together with counts of records containing valid, missing or invalid dates, and clarifies that it operates on the configured IATI dataset. This is adequate transparency for a read-only reporting tool.

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

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

The purpose is front-loaded in the first sentence, followed by scannable bullet lists for parameter values and output behavior. The IATI glossary adds useful domain context without redundancy, though it is slightly longer than strictly necessary.

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

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

For a tool with one optional parameter, an output schema, and no annotations, the description is complete: it defines the parameter values, describes the computed result, and clarifies relevant IATI terminology. An agent has everything needed to select and invoke the tool correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema has 0% description coverage and only provides a title and default for date_kind. The description fully compensates by enumerating the three allowed values (activities, transactions, all) and defining what each means in the IATI context.

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: 'Report the date range covered by the configured IATI data.' The explanation of activity dates vs transaction dates and valid/missing/invalid counts makes the tool's purpose distinct from sibling transaction-total and search tools.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explains how to choose date_kind values, but it does not explicitly state when to prefer this tool over siblings such as mcp_iati_file_overview or mcp_iati_transaction_totals_by_year. The intended use is implied by the purpose, but no explicit when/when-not guidance or alternatives are provided.

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

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

With no annotations provided, the description carries the burden of behavioral disclosure. It explains that partial matches are accepted, the lookup is in English, and the return is a table of matching glossary terms with definitions. This meaningfully describes the tool's behavior beyond the bare schema, though it does not cover edge cases like no-match behavior or multiple-term handling.

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 well structured with a clear overview, usage guidance, and explicit Args/Returns sections. Every sentence adds useful information, and important details like examples and partial-match behavior are included without unnecessary verbosity.

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

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

For a simple one-parameter lookup tool with an output schema, the description is complete. It covers purpose, usage, parameter semantics, and expected return format, while the output schema handles formal return typing. No critical information is missing for an agent to invoke 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?

The schema has 0% description coverage, so the description must fully compensate. It does: the Args section explains that 'term' is a word or phrase in English, gives concrete examples ('disbursement', 'policy marker'), and notes that partial matches are accepted. This is exemplary parameter documentation.

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 clear verb ('Explain') and resource ('an IATI term according to the standard's glossary'), making the tool's purpose immediately understandable. It also lists glossary categories, which helps scope what the tool covers. It does not explicitly name a sibling alternative, but the glossary-lookup function is distinct from the other data-search and filtering tools.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explicitly says it is 'useful for questions like "what does X mean?" or "what is the difference between X and Y?"' and advises calling it once per term. This gives clear when-to-use guidance, though it does not state when not to use it or name specific 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?

With no annotations, the description carries the transparency burden and largely fulfills it by detailing exactly what the summary includes and clarifying IATI-specific semantics. It does not explicitly state that the tool has no side effects, but 'Summarise' and the read-only nature of an overview make this reasonably clear.

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 a practical summary and usage guidance before the longer glossary. The glossary is lengthy but earns its place by defining IATI terms that an agent would otherwise need to infer, though some definitions could be trimmed without harming understanding.

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 overview tool with an output schema, the description is complete: it states the tool's purpose, the types of questions to route to it, the full list of returned aggregates, and the domain vocabulary needed to interpret them. Nothing essential 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?

The tool takes zero parameters, so there is no parameter detail for the description to add. The baseline of 4 applies, and the description wisely spends its space clarifying the output and domain terms instead.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description opens with a clear verb and resource: 'Summarise the contents of the configured IATI file.' It enumerates the exact questions the tool answers and the output categories, making its scope unmistakable and distinct from sibling search, filtering, and totals-by-dimension tools.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

It explicitly says 'Use this tool for general questions such as...' and lists representative queries, giving an agent clear selection criteria. It does not name alternatives or state when not to use it, but the general-questions framing strongly differentiates it from more specific sibling tools.

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

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

With no annotations, the description carries the transparency burden. It discloses accepted input formats (ISO code or published country name), the default limit behavior, and the returned table's composition (identifiers, titles, statuses, recipient-country info). It does not detail exact-vs-partial matching or no-result behavior, but the core behavior is clearly specified.

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 operational details are front-loaded and organized into purpose, accepted values, prerequisite, Args, Returns, and glossary. The relevant IATI terms section is somewhat long, but each term connects to input or output semantics and is not 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 two-parameter filter tool with a declared output table, the description is largely sufficient and even includes the prerequisite lookup call. It could be improved by relating this tool to search_activities or other filtering alternatives, but no critical invocation detail 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 description coverage is 0%, but the Args section fully explains both parameters: country accepts a code or name, and limit controls the maximum number of returned activities with a default of 10. The description adds examples and clarifies value formats, completely compensating for the empty schema descriptions.

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 opening sentence 'Filter IATI activities by recipient country' is a specific verb+resource statement that clearly names the operation and target. It is immediately distinguishable from siblings like list_recipient_countries or search_activities, and the accepted-input note adds further precision.

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 actionable sequencing guidance by telling the agent to call list_recipient_countries first when country codes or names are unknown. It does not explicitly contrast this tool with search_activities or state when not to use it, so it stops short of a full alternatives statement.

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

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

With no annotations present, the description carries the full burden, and it does well by framing the call as non-mutating and specifying the return contents: 'status code', 'human-readable label', and 'number of activities'. It could add more edge-case behavior, such as what happens when no IATI data is loaded, but the read-only nature and output shape are transparent.

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 primary purpose, then usage, return shape, and relevant IATI terminology, keeping the most actionable information early. It is slightly redundant by later restating 'activity statuses' as 'lifecycle statuses', but every section otherwise 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?

For a zero-parameter, non-mutating list tool with an output schema present, this description is complete: it explains the data scope, the intended use, the return columns, and the domain vocabulary. An agent has enough to decide when to call it and what to expect.

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 accepts zero parameters, so the input schema already describes everything that can be passed; the 0-param baseline is 4. The description adds useful context by scoping the result to the currently loaded IATI dataset, which helps even with no arguments.

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 opening sentence names a specific verb ('List') and a specific resource ('activity statuses present in the loaded IATI data'), then clarifies they are lifecycle statuses. This resource is distinct from sibling list tools such as list_sectors or list_reporting_organisations, so an agent can tell which list is intended without opening schemas.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explicitly says to use the tool 'before filtering or analysing activities' to discover which lifecycle statuses are available, providing clear context for when it is useful. It does not name alternative tools or state when not to use it, so it falls just short of fully explicit routing.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It states what the result includes: 'each code, its readable value, its vocabulary when applicable, and the number of records containing it.' This goes beyond the schema and clarifies the tool's non-mutating, exploratory nature, though it does not address limit behavior or invalid-category handling.

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 well structured and front-loaded with purpose and usage, but it becomes lengthy with a substantial glossary of 'Relevant IATI terms.' While these definitions add domain context, many are verbose and some are unnecessary for simply selecting a category value, making the description less concise than it could be.

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

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

For a two-parameter tool with an output schema, the description is largely complete: it covers the required category values, the result contents, and domain vocabulary. The main gap is that the optional 'limit' parameter's effect is not described, and behavior for an invalid category is not addressed, but an agent can still invoke the tool correctly with the provided information.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description must compensate. It significantly helps the 'category' parameter by enumerating exact supported values, which are not provided as enums in the schema. However, the 'limit' parameter is not explained beyond its schema default of 100, leaving its semantics and effect on results undocumented.

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: 'List the values present in a categorical IATI field,' followed by an enumerated list of supported categories. This makes the tool's purpose clear, but it does not differentiate it from sibling tools like mcp_iati_list_activity_statuses or mcp_iati_list_sectors, which may overlap in functionality.

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 explicit usage context: 'Use this tool to explore available values before applying filters.' This tells the agent when to invoke it, but it does not contrast it with the specialized sibling list tools or state when those alternatives should be preferred, so exclusions are missing.

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

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

With no annotations to lean on, the description takes on the burden of explaining behavior. It discloses the output shape (a table with country code, name, and activity count), clarifies that 'recipient countries' includes regions, and grounds the result in the loaded IATI data. This goes well beyond a tautological statement.

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 well structured with a clear lead sentence, a usage note, a returns summary, and relevant IATI terms. It is slightly longer than strictly necessary, and the IATI definitions are auxiliary, but every section earns its place and the main purpose is front-loaded.

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 list tool, the description is complete: it states the scope, the intended use, the return format, and domain-relevant definitions. Since an output schema exists, the return value explanation is a bonus. Nothing needed to invoke the tool 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?

The tool has zero parameters, so the baseline is 4. The description adds no parameter-specific detail, but none is needed because the input schema is empty. The usage guidance about discovering country codes is contextual rather than parameter-related.

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: 'List the recipient countries present in the loaded IATI data.' It clearly distinguishes this tool from sibling list tools like mcp_iati_list_sectors and mcp_iati_list_reporting_organisations by focusing on recipient countries and tying it to the filtering workflow.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explicitly states when to use it: 'Use this tool to discover which country codes are available before filtering activities by recipient country.' This gives clear context, although it does not mention any alternatives or when not to use it, so it stops short of a 5.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It states that the tool returns a table containing organisation reference, name, and number of activities reported, and it clarifies an important conceptual nuance about reporting organisations. This is adequate for a simple read-only list with no parameters, although it omits minor details like ordering or whether the list is complete.

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 main sentence is direct and front-loaded, and the return-format section is useful. However, the 'Relevant IATI terms' section repeats the reporting-organisation definition almost verbatim from the earlier paragraph, and the IATI activity definition is not necessary for invoking this tool. The structure is clear but the content could be tightened.

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 tool with an output schema already present, the description supplies the needed context: it names the data source, the return shape, and the distinguishing concept of reporting organisations. Nothing essential for selecting or invoking this tool appears to be missing, though it could have been more concise.

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 has zero parameters, so the input schema already fully covers the invocation surface; the description does not need to explain parameters. The baseline for a zero-parameter tool is therefore strong, and the description adds no irrelevant parameter information.

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: 'List the organisations that report activities in the loaded IATI data.' It also clarifies the reporting-organisation concept by distinguishing it from funding and implementing organisations, which helps narrow the tool's meaning. However, it does not explicitly distinguish itself from sibling tools such as transaction_totals_by_organisation, so it stops short of full sibling differentiation.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description conveys that this tool is for reporting organisations and that these are not necessarily funding or implementing organisations, which gives useful context for choosing it. It does not explicitly name alternatives or state when not to use this tool, so the usage guidance is more implied than explicit.

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

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

With no annotations, the description carries the burden of behavioral disclosure. It does state the return shape as 'a table containing vocabulary, sector code, sector name and number of related activities,' which is useful. However, it does not disclose details such as ordering, behavior when data is empty, or whether the operation is strictly read-only, leaving some ambiguity.

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 well structured with clear sections for purpose, arguments, return value, and relevant IATI terms. It is slightly longer than necessary due to the vocabulary definitions, but those definitions support correct use and the key information is front-loaded.

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 tool with an output schema, the description covers the core needs: what the tool lists, when to use it, what the result table contains, and the parameter meaning. Minor gaps such as handling of missing data or ordering do not significantly impair an agent's ability to invoke 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?

The input schema has no parameter descriptions, but the description explains 'limit' as the 'Maximum number of sector values to return' with a default of 100. This adds meaningful semantics beyond the bare integer type and default value 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 states a specific verb and resource: 'List the sectors present in the loaded IATI data.' It also clarifies that the tool returns sector codes and vocabularies, which distinguishes it from sibling list tools like mcp_iati_list_activity_statuses or mcp_iati_list_recipient_countries.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explicitly says to use the tool 'to discover the available sector codes and vocabularies before performing sector-based analysis.' This gives clear context for when to call it, though it does not name alternatives or explicitly state when not to use 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?

No annotations are present, so the description carries the transparency burden. It explains the intended invocation context and gives an example reason, but it never states what actually happens when the tool is called, such as whether it returns no data or simply records the reason. The role is inferable from the name but not fully 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?

The description is compact and well-structured, with the call condition, an Args section, and an example. There is no filler, and the most important routing information appears 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 simple fallback tool with one optional parameter and an output schema, the description covers when to use it, why to use it, the parameter semantics, and a usage example. Nothing essential is missing for an agent to invoke 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?

The schema only provides the parameter name, type, and default, with no description. The description adds meaningful semantics by explaining that 'reason' is a brief one-sentence explanation of why no tool applies, and it includes a concrete example. This fully compensates for the 0% schema description coverage.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly identifies this as the deliberate fallback tool, stating that it is for topics that are not IATI activities or questions outside the scope of the loaded data. This distinguishes it from the IATI data tool siblings by defining exactly what it is not.

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 explicit when-to-use rule: call only when no other tool can answer the question. It also provides an example call. It does not enumerate sibling alternatives, but the routing criterion is specific enough to guide selection away from them.

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

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

No annotations are provided, so the description carries the full behavioral burden. It discloses that the match is a case-insensitive substring search, that limit controls maximum results, and that the response is a table containing identifier, title, and status. This is transparent enough for a simple read-style search tool, though edge cases like empty results are not mentioned.

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 well-structured with clear Args/Returns sections and front-loads the main purpose. The 'Relevant IATI terms' block is somewhat verbose but provides useful domain context for an AI agent and does not overshadow the essential usage 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?

The tool is simple, has only two parameters, and an output schema is already present. The description covers the use case, parameter semantics, result contents, and domain terminology, so an agent has everything needed to select and call this tool correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

With 0% schema description coverage, the description fully compensates by explaining both parameters: text is a case-insensitive substring to search for in the title, and limit is the maximum number of results with a default of 10. This adds real meaning beyond the bare schema types.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool 'Search IATI activities whose title contains the given text', naming a specific verb, resource, and matching mechanism. It also positions itself as a first step toward discovering an IATI identifier, which helps distinguish it from the sibling activity_summary tool.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explicitly says it is useful as a first step to discover an activity's IATI identifier before requesting its summary with activity_summary. This gives a clear when-to-use signal and names a relevant sibling, though it does not enumerate exclusions for other sibling tools.

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

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

No annotations are provided, so the description carries the full burden. It discloses that rankings are calculated independently per currency to avoid cross-currency comparisons, and it lists the return fields. However, it does not disclose potential edge cases, performance behavior, default currency handling when currency is null, or error conditions. It explains the expected behavior but is not exhaustive.

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 core description is concise and front-loaded with the main purpose and key behavior. However, the appended glossary of IATI terms is lengthy and generic, not tool-specific. While informative, it inflates the description size significantly and could be truncated or moved to documentation. The Args/Returns structure is clear, but overall conciseness suffers from the glossary overload.

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

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

The tool has an output schema, so return values are covered externally. The description explains the parameters sufficiently and the glossary provides background on IATI concepts. Given the tool's simplicity (three optional parameters) and the existence of the output schema, the description gives enough for an agent to call it correctly. The only gap is explicit usage guidance versus siblings, but that is a separate dimension.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description must compensate. It does so effectively: transaction_type lists acceptable values ('commitment, out commitment, disbursement, 2 or 3'), currency gives examples ('USD or EUR'), and limit specifies 'Maximum results to return per currency. Default: 10.' This adds meaning beyond the raw schema types, though it leaves some conceptual details (e.g., the meaning of 'out commitment') to the glossary.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific verb and resource: 'List activities with the highest commitment or disbursement totals.' It also clarifies the per-currency ranking logic, which distinguishes it from sibling tools like transaction_totals_by_* that aggregate totals. This is a clear, unambiguous purpose that would let an agent pick this tool without opening schemas.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explains what the tool does but does not explicitly state when to use it versus alternatives. It mentions the ranking per currency and parameters, but there is no direct guidance on when to prefer this over e.g. mcp_iati_transaction_totals_by_country or mcp_iati_activity_transactions. Usage is implied from the purpose, but no exclusions or alternative conditions are given.

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

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

With no annotations provided, the description carries the full burden, and it discloses useful behavioral details: amounts in different currencies and transaction types are reported separately, missing country names fall back to codes, and missing country data falls back to 'Unknown recipient country'. It also clarifies the return table's contents, though it does not mention pagination, ordering, or read-only status.

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 well organized with Args, Returns, and Relevant IATI terms sections, and the key behavior is front-loaded in the first sentence. The IATI glossary is somewhat lengthy, but it provides useful domain context for an agent unfamiliar with IATI terminology.

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

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

The description is complete enough to call the tool correctly: it covers parameter values, output columns, fallback behavior, and aggregation semantics. An output schema exists, and while the description goes beyond it usefully, it could still be improved by explicitly noting whether only one transaction_type is returned per call and how results are ordered.

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%, but the description fully compensates by explaining all three parameters. It gives accepted values for transaction_type ('commitment', 'out commitment', 'disbursement', '2', or '3'), states that currency is an optional code with examples, and specifies limit as the maximum grouped rows with a default of 50.

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: 'Group commitments and disbursements by recipient country.' It clearly defines the grouping dimension (country) and output (table with country, type, currency, total), which distinguishes it from sibling tools that group by year, organisation, or sector.

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 intended use is implied through the tool name and the grouping-by-country statement, but the description does not explicitly state when to prefer it over transaction_totals_by_year, transaction_totals_by_organisation, or transaction_totals_by_sector. No alternatives or exclusions are mentioned, so the agent must infer selection from naming context.

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

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

With no annotations provided, the description carries the burden of behavioral disclosure. It does well by explaining that amounts with different currencies and transaction types are reported separately, that the reporting organisation is not necessarily the funder or implementer, and that the result is a table with organisation, transaction type, currency, and total amount. This goes beyond the tool name and adds meaningful context.

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 core purpose, arguments, and return description are front-loaded and clearly separated. However, the extensive 'Relevant IATI terms' glossary is lengthy and contains generic domain definitions that are not necessary for calling this specific tool, making the description more bloated than needed.

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

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

For a tool with a single optional parameter and an output schema, the description covers the key semantics: grouping dimension, currency/type separation, output fields, and limit behavior. It is nearly complete; only minor details like output ordering or handling of empty results are absent.

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%, but the description compensates by fully documenting the only parameter: 'limit: Maximum number of grouped rows to return. Default: 50.' This adds meaning beyond the schema's bare 'Limit' title and is sufficient for correct invocation.

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: 'Group commitments and disbursements by reporting organisation.' This states exactly what the tool does and the output table is listed. It is clear, though it does not explicitly contrast with sibling aggregation tools like mcp_iati_transaction_totals_by_year, by_sector, or by_country.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides no guidance about when to use this tool versus the many sibling tools (by year, by sector, by country, activity_transactions). There are no usage conditions, exclusions, or alternative recommendations. Users must infer the appropriate selection from the tool name 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?

With no annotations, the description carries the full burden, and it does well: it discloses that amounts are distributed using published sector percentages, that different vocabularies and currencies are reported separately, and that a table is returned. It does not explicitly state that this is a read-only operation, but the 'Returns a table' framing makes that reasonably clear.

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 tool summary, Args, and Returns sections are well-structured and front-loaded. However, the 'Relevant IATI terms' glossary is long and only tangentially operational; much of it defines domain concepts rather than helping an agent invoke the tool. It is not harmful, but it prevents the definition from being tightly concise.

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-style aggregation tool, the description provides the core needed context: allocation logic, grouping behavior, parameter meanings, defaults, and return columns. The missing usage guidance is a gap, but the presence of an output schema and thorough parameter documentation makes the tool callable without further 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 description coverage is 0%, so the description must fully compensate. It does: every parameter is covered, including accepted transaction_type values ('commitment, out commitment, disbursement, 2 or 3'), optional examples for currency and vocabulary, and the limit default of 50.

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 opening line states a specific operation and resource: allocating commitments and disbursements across sectors. The 'Returns' section clarifies that it produces a grouped table of totals. It does not explicitly contrast itself with sibling totals tools (by_year, by_country, by_organisation), so it stops short of full sibling differentiation.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

There is no explicit guidance about when to use this tool versus transaction_totals_by_year, transaction_totals_by_country, or transaction_totals_by_organisation. The sector-specific scope is implied by the name and first sentence, but no alternatives, prerequisites, or exclusions are stated.

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

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

No annotations are provided, so the description carries the full disclosure burden. It reveals key behavioral details: only commitments and disbursements are included, different currencies are never merged, and the result is a chronological table. For a read-only aggregation tool this is solid, though it does not explicitly state behavior when year_from/year_to are omitted.

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 opening sentence is clear and the Args/Returns sections are well structured. However, there is redundancy between 'Group commitments and disbursements...' and 'Only commitment and disbursement transactions are included,' and the 'Relevant IATI terms' glossary is long, containing definitions that are not all essential for invoking this specific tool.

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

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

For a tool with two optional parameters and an output schema, the description covers the core invocation contract: purpose, filter parameters, included transaction types, output columns, and the important currency-separation caveat. It lacks explicit guidance on preferring sibling transaction tools or on omitted-year behavior, but the essential context is present.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, and the description compensates by explaining both parameters: 'year_from: Optional first year to include' and 'year_to: Optional last year to include.' This adds meaning beyond the bare integer/null schema and default values. It stops short of a 5 because it does not clarify inclusivity or open-ended ranges.

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: 'Group commitments and disbursements by year and currency.' It names the two transaction types included and the return format, which clearly differentiates it from sibling tools like mcp_iati_transaction_totals_by_organisation or by_sector.

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 an explicit scope condition: 'Only commitment and disbursement transactions are included,' which tells an agent when not to use the tool. However, it does not explicitly name alternative tools or state a when-to-use/when-not-to-use rule relative to mcp_iati_activity_transactions or the other totals_by_* tools.

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