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

With no annotations provided, the description carries the full burden of disclosing behavior. It states that the tool aggregates server-side, covers a full year, and returns totals and counts, which is a clear read-only query profile. It does not mention authorization, rate limits, or default sort/limit behavior, but for a read-only aggregation tool this is a reasonable level of disclosure.

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 achieve both clarity and economy: the first packs the core behavior and output, the second provides concrete use cases and a contrast with paging. There is no fluff, and the most decision-relevant 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 tool with 7 parameters and no output schema, the description gives enough context to select and invoke it correctly: the aggregation behavior, return fields, and example use cases. Minor gaps remain, such as the default behavior when group_by is omitted and the effect of limit, but these do not prevent an agent from making a correct first call.

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 already covers year, region, group_by, donor_country, and operating_unit with descriptions (71% coverage), and the description adds meaning by illustrating the group_by dimensions and tying them to example questions. However, limit and sort_by have no schema descriptions and the description does not explain them either, leaving a gap that is only partially compensated.

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 ('Aggregate a full year of UNDP projects') and enumerates the grouping dimensions and return fields (totalled budget, expenditure, project counts). It further differentiates from sibling tools by emphasizing server-side summarization 'instead of paging through thousands of projects', making the tool's role unmistakable.

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 concrete example questions ('which countries got the most funding in 2023', 'how much did Germany fund') and contrasts with the alternative approach of paging through projects. While this clearly implies 'use this instead of search_projects for aggregate questions', it does not explicitly name that sibling or state exclusions like 'do not use this for individual project details'.

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 adds meaningful context beyond the schema: the upstream document is large, projects are paginated, and outputs are summarised by default. This helps agents anticipate response size and default verbosity, though it does not detail pagination mechanics or output shape.

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 with no filler. The main resource is front-loaded, and the pagination/summarisation caveats are delivered immediately after, giving agents the most decision-relevant information 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 6-parameter tool with no output schema and no annotations, the description covers the core purpose, return contents (projects, outputs, subnational locations), and important behavior (pagination and summarisation). It lacks explicit response-structure details and pagination parameter guidance, but is largely sufficient for correct invocation.

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

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

Schema description coverage is 67%, so the schema already documents iso3, query, include_outputs, and include_locations. The description adds value by stating that outputs are summarised by default, which clarifies the include_outputs parameter. However, it does not explain limit/offset semantics beyond the generic pagination mention.

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 starts with a specific verb and resource: 'Get one operating unit's (country office's) full project portfolio'. It also clearly distinguishes itself from siblings like undp_list_operating_units (list vs. one unit) and undp_get_project (project vs. operating-unit portfolio).

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

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

No guidance is given for when to use this tool versus alternatives such as undp_search_projects or undp_get_project. The description implies this is the 'full portfolio' retrieval path but never explicitly states conditions, exclusions, or trade-offs between 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 burden of explaining behavior. It discloses what data the tool returns and the breakdown dimensions (fiscal year, donor), and 'Get one project output' signals a read-style operation. It does not mention error cases or authentication, but for a single-record retrieval this is a reasonable level of transparency.

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

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

The description is a single, front-loaded sentence that leads with the action and resource, then enumerates the returned content and the ID source. There is no filler or redundant restatement of the tool name.

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 required parameter fully covered by the schema and no output schema, the description is complete enough to call correctly. It states exactly what will be returned and where to get the required ID, so no essential information 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 schema already describes output_id with an example, so baseline is 3 for high schema coverage. The description adds useful semantic context beyond the schema by stating that output IDs come from undp_get_project, which helps the agent locate valid identifiers. This extra guidance justifies a score above 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?

The description states a specific verb ('Get'), a specific resource ('one project output'), and enumerates the returned fields: CRS sector, gender marker, SDG tags, and budget/expenditure/disbursement by fiscal year and donor. It also distinguishes itself by noting output IDs come from undp_get_project, making it easy to differentiate from sibling 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 clearly implies when to use this tool: when you need detailed data for a single project output. It also provides a routing hint by saying output IDs come from undp_get_project, which tells the agent how to obtain valid inputs. It does not explicitly name alternatives or exclusion conditions, but the context is sufficient for a simple getter.

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 states 'Get' which implies a read-only operation, but does not explicitly disclose safety, authorization requirements, rate limits, or error behavior. The description lists what is returned but not the response format or potential failure modes (e.g., project not found). This is adequate for a simple retrieval but lacks explicit behavioral guarantees.

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

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

The description is a single, well-structured sentence that front-loads the core purpose, then lists content, and ends with ID provenance. There is no fluff or repetition. Every clause earns its place, making it highly scannable for an agent.

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

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

With no output schema, the description partially fills the gap by listing the categories of data returned (dates, budget, outputs, locations, documents). It also mentions the optional include toggles, giving the agent awareness of response tailoring. However, it does not specify the exact structure or type of the return value (e.g., a JSON object), nor any error handling. Given the tool's simplicity, this is nearly complete.

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

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

Schema coverage is 100% and the schema descriptions are already clear for each parameter (e.g., 'Include the project's outputs'). The description adds value by explaining the origin of the project_id and the fact that it's a full record, but it does not elaborate on parameter semantics beyond the schema. Baseline 3 is appropriate when the schema handles 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 clearly states the verb ('Get') and resource ('full record for one UNDP project'), and enumerates the content: dates, budget and expenditure by fiscal year, outputs, subnational locations, and linked documents. It also distinguishes itself from siblings by noting project ids come from undp_search_projects, making it obvious this is the single-record fetch 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 tells the agent where to obtain project ids ('come from undp_search_projects'), which is essential routing guidance. It implies the tool is for when you already have a specific project id, and the optional include_* parameters signal that the caller can tailor the response. However, it does not explicitly contrast with alternatives like undp_get_output or undp_aggregate_projects, leaving some inference to the agent.

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?

There are no annotations, so the description carries the full burden. 'List' implies a read-only operation and the description reveals that the output includes marker types and ids, but it doesn't state output shape, default behavior when optional filters are omitted, or whether include_top_donors changes the result set. Adequate but with clear gaps.

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 focused sentences with no filler. The first sentence defines the resource and gives examples; the second sentence is front-loaded with the downstream use.

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 optional-filter list tool, the essential information is present: what it lists, what the output contains, and how the output is consumed. With no output schema, a brief note on the default result set or response format would make it fully complete, but the current context is sufficient for correct invocation.

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

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

Schema description coverage is 100%, so the parameters are already documented by the schema. The description adds a helpful connection to downstream filters but does not add meaning to the individual parameters beyond what the schema provides.

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

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

The description uses a specific verb and resource ('List Our Approaches — policy markers'), gives examples ('gender, capacity development, and similar'), and connects the result to marker_type/marker_id filters on undp_search_projects. This clearly separates it from sibling list tools for operating units, SDGs, etc.

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 tells the agent that the returned marker types and ids are intended to feed the marker filters on undp_search_projects, giving a concrete when-to-use context. It doesn't explicitly enumerate alternatives to avoid, but this is not necessary given the clear downstream purpose.

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 must carry the behavioral burden. The verb 'List' implies a read-only operation, but the description does not explicitly state safety, return format, or side effects. It adds useful context about classifying UNDP outputs, but does not disclose additional behavior beyond the verb.

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

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

The description is a single, focused sentence with no filler. It front-loads the purpose ('List the codes') and immediately provides a usage example, making it easy to scan.

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 list tool with one optional parameter and no output schema, the description covers purpose, use case, and an example. It does not mention the return structure or limits, but these are likely trivial for a code list, so the description is sufficient.

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 query parameter is fully described in the schema (case-insensitive match on sector name or code), so schema coverage is 100%. The description adds no additional meaning about the parameter beyond its purpose; the schema already handles it, so the baseline of 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 clearly states the verb 'List', the resource 'OECD DAC CRS sector codes', and gives an example (15162 'Human rights'). It also specifies its use case for decoding the `crs` field, which distinguishes it from sibling list tools like undp_list_operating_units.

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 provides a concrete use case ('useful for decoding the `crs` field'), telling an agent when to invoke it. It does not explicitly name alternatives, but the naming convention and sibling context make the purpose 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?

With no annotations provided, the description must carry the behavioral burden. It discloses query-vs-list behavior and that results include budget and contributing organisations, but it does not state defaults, pagination behavior, or whether include_organisations significantly changes response size (the schema's 'Verbose' note helps but lives outside the description).

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, no filler, with the core purpose front-loaded and the invocation pattern immediately following. Every clause contributes information, and the formatting makes it scannable.

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 five-parameter listing tool with no output schema and no annotations, the description captures the main purpose and two usage modes but omits default list size/ordering and pagination expectations. These are material gaps for an agent deciding whether to pass limit/offset/sort_by, so the description is adequate but not complete.

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

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

Schema coverage is only 40% (query and include_organisations have descriptions; limit, offset, sort_by do not beyond the enum). The description adds meaning by tying query to lookup and 'ranked by contribution' to sorting, but it leaves limit and offset semantics entirely to the schema's bare 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?

States a specific verb ('List') and resource ('countries and territories that contribute funding to UNDP'), and adds the distinguishing content ('total budget and the contributing organisations behind each'). This sets it apart from sibling list tools like undp_list_operating_units or undp_list_regions based on the donor-country domain alone.

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 clear in-tool usage ('Use query to look one up, or list them ranked by contribution'), so an agent knows when to query versus list all. However, it never addresses when to choose this tool over the sibling undp_search_donors or another alternative, leaving that selection to inference.

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

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

With no annotations and no output schema, the description carries the full burden of disclosing behavior, but it only states that it lists counts and optionally top donors. It does not clarify filtering behavior, defaults when optional parameters are omitted, how budget_source is interpreted, or what the response shape looks like.

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, front-loaded with the resource and core output metrics, with the optional behavior in a separate sentence. Every sentence contributes information an agent needs to understand what the tool returns.

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 for a simple list tool and names its main outputs, but it omits how year, budget_source, and operating_unit combine or what happens when none are supplied. Minor gaps remain given there is no output schema and no annotations.

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

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

Schema description coverage is 100%, so the schema already documents the four parameters. The description adds no parameter-specific meaning beyond the schema, except for 'Optionally include each area's top donors', which maps to include_top_donors. Baseline 3 is appropriate given the schema does most of the work.

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 a clear action ('List'), a precise resource ('UNDP's focus areas / 'Our Focus' thematic pillars'), and the included metrics (budget, expenditure, project and donor counts). This distinguishes it from sibling list tools like undp_list_regions or undp_list_sdgs by naming a unique resource and output content.

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

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

The description gives no guidance on when to use this tool versus the many sibling list/search/aggregate tools. It also does not explain how optional parameters such as year, budget_source, or operating_unit affect results, leaving usage entirely to inference.

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

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

No annotations are supplied, so the description carries the behavioral disclosure burden. It does state the return content and the iso3 resolution purpose, but it does not mention pagination, default result limits, or whether all units are returned by default. This is a meaningful gap for a list tool with optional limit and offset parameters.

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 carry the full message with no filler. The purpose is front-loaded, and the usage guidance follows immediately. Every clause 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?

With no required parameters CST, no output schema, and no annotations, the description provides the essential call rationale and return content. It is not fully complete because default pagination behavior and the relationship to undp_get_operating_unit are left implicit, but a correct first call is well supported.

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 60%, with query, sort_by, and fund_type already documented. The description reinforces the query-to-iso3 relationship, but it adds little for the undocumented limit and offset parameters. The conventional names make them understandable, so a baseline 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 names a specific verb ('List'), a specific resource ('UNDP operating units'), and the fields returned ('headline budget, expenditure and project counts'). It also clarifies that these units include country offices and regional/global units, which distinguishes it from region or SDG list siblings.

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

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

The description gives an explicit use case: 'Use this to resolve a country name to the iso3 code that every other tool's operating_unit filter expects.' This clearly tells an agent when to call it, though it does not name alternatives or state 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, the description carries the behavioral burden; it does disclose that the output contains aggregate budget, expenditure, project counts, and optionally embedded countries. However, it does not mention likely relevant traits such as pagination, output size limits, authentication, or a return envelope, and the 'Adds substantial output' warning lives only in the parameter schema, not the tool description.

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 front-loads the resource and action, enumerates the exact bureaux, and mentions the optional parameter. Every clause carries useful information 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?

Given the low complexity, complete schema coverage, and no output schema, the description is nearly complete for selecting and invoking the tool: it identifies the region set, the returned aggregate fields, and the optional include_countries behavior. The omission of return envelope or pagination details is minor for a simple list 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 for the single parameter is 100%, so the baseline is 3. The description mostly restates the schema's 'member-country list' idea as 'optionally including the countries in each region' and adds no deeper semantic detail about include_countries, while the schema itself already provides the useful output-size warning.

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

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

The description uses a specific verb and resource: it says 'List the UNDP regional bureaux' and names the exact bureaux (RBA, RBAP, RBEC, RBLAC, RBAS, and global units). This clearly distinguishes it from sibling list tools like undp_list_operating_units and undp_list_sdgs by identifying a unique resource and the aggregate metrics returned.

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 when the tool is appropriate (when a caller wants UNDP regional bureau rollups), but it does not explicitly state when to prefer it over alternatives such as undp_list_operating_units or undp_aggregate_projects, and it gives no when-not-to-use guidance. For a simple list tool the context is adequate but the routing 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?

With no annotations, the description carries the transparency burden. It clarifies the read-only nature through the verb 'list', states what is returned (counts, budget, expenditure), and warns that target-level detail is intended for a single SDG. It does not discuss pagination, limits, or auth, but these are minor for a straightforward list operation.

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 sentences with no filler. It front-loads the core purpose and return content, then lists filtering options and the one special behavior worth calling out. 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?

The description is complete for this tool's complexity: it names what is returned, the available filters, and the target-level mode. Since there is no output schema, the stated return fields are important and present; parameter details are fully covered by the input 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 the parameters are already well documented. The description mostly restates the filtering parameters and the `include_targets` mode without adding meaning beyond what the schema already provides, 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 states a specific verb and resource: 'List the 17 Sustainable Development Goals' with UNDP project counts, budget and expenditure. It also distinguishes itself from target-level listing tools by explicitly reserving `include_targets` for target-level detail on a single SDG.

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 clear usage context: the tool lists aggregate SDG funding data and can be filtered by year, operating unit, and budget source. It also indicates when to enable `include_targets`, though it does not explicitly name sibling alternatives or say when not to use this tool.

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 disclosing basic behavior. It communicates that this is a read-style list operation and that results carry UNDP funding data, but it does not mention pagination behavior, limits, output shape, or any side effects beyond 'list'.

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

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

Two compact sentences with no filler. The core resource and granularity is front-loaded, and the filter options are stated directly in the second sentence.

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?

Adequate for a simple list tool, but gaps remain: no output schema, no annotations, and no mention of limit, offset, or include_top_donors behavior. An agent could still call it correctly with the filter parameters, but pagination and optionality are left under-specified.

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 67%, with limit and offset undocumented. The description reinforces the meaning of the target parameter by showing sub-goal examples and adds the funding context, but it does not compensate for the undocumented pagination parameters or explain how filters combine.

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 action ('List') and resource ('SDG target-level data') and clarifies granularity with the parenthetical sub-goal examples ('1.1, 1.2 …'). It also names the associated data ('UNDP funding'), which distinguishes it from the sibling undp_list_sdgs 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 makes clear it is used for listing target-level SDG data and filtering by SDG code, target id and year. However, it does not explicitly say when to choose this over alternative sibling tools or provide exclusions, leaving usage guidance mostly implied.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It states the tool returns a list of six signature solutions with aggregate funding and project counts, which goes beyond the tool name and adds useful behavioral context. There are no unexpected side effects implied, and the scope of the output is clearly bounded to six items.

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

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

The description is a single, tightly worded sentence with no wasted words. The core action and resource are front-loaded, and the parenthetical adds useful context without bloating the text.

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 list tool with one optional boolean parameter and no output schema, the description provides the essential return information: six signature solutions with aggregate funding and project counts. The optional parameter behavior is already covered by the schema. Nothing an agent needs to select and call this 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?

Schema description coverage is 100%, since the single parameter include_details already has a clear description in the schema. The tool description adds no extra information about the parameter, but it does not need to because the schema fully documents it. This meets the baseline for schema-covered parameters.

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

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

The description names a specific verb ('List') and resource ('UNDP's six signature solutions'), and adds clarifying context by calling them 'the Strategic Plan delivery areas' and specifying the output includes aggregate funding and project counts. This clearly distinguishes it from the sibling list tools, which target different entities like operating units, regions, SDGs, and focus areas.

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 makes it clear this tool is for listing signature solutions, so an agent can infer when to use it. However, it gives no explicit guidance on when not to use it or how it compares to sibling list tools, such as focus areas or approaches. The usage guidance is implied rather than stated.

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

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

With no annotations, the description carries the full behavioral burden. It usefully reveals that the index is large, that a query is mandatory, and that it returns the donor id used as budget_source. However, it does not describe the response shape, pagination behavior, empty-result handling, or what happens when no match is found.

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 three concise sentences with no filler. It front-loads the tool's purpose, then gives the key usage constraint and the most important return-value fact. 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 the tool's relative simplicity, the description is nearly complete: it identifies the required query, explains why it is needed, and states the crucial return value (donor id used as budget_source). The main omission is a description of the output format, but enough is provided for correct invocation.

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

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

The schema documents query and country but leaves limit and offset undocumented. The description adds meaning by explaining why query is required and that it matches on donor name or id, but it does not compensate for the missing limit/offset semantics. Overall coverage is approximately 50%, so the description only partially adds value 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 uses the specific verb 'Search' and names a precise resource: 'the index of organisations that fund UNDP (governments, multilaterals, foundations, private sector)'. It also states search keys (name or id), clearly distinguishing this tool from sibling tools that search projects or list operating units and regions.

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 notes that a query is required and explains why: the full index is too large to list. This gives clear context for when to use the tool. It does not explicitly name sibling alternatives, but no sibling appears to be a direct donor-search alternative.

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 discloses that results are paginated, that the tool returns a compact record per project, and that the query parameter searches across ALL matching projects (not just one page) and costs extra requests on a cold cache. This is meaningful behavioral context beyond what the schema provides. It doesn't mention rate limits or auth, but the disclosed behaviors are substantial.

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 with zero waste. The first sentence states the core function and filters, the second describes the return format and pagination, and the third routes to the sibling tool. Every sentence earns its place and the most important 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 search tool with 14 parameters and no output schema, the description is quite complete. It covers the return format, pagination, and the key alternative tool. It doesn't explain the meaning of each filter code (e.g., what a signature solution code looks like), but the schema descriptions cover those. The main gap is that it doesn't mention how to discover valid filter values (e.g., using undp_list_* tools), but the sibling names make that inferable.

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 93%, so the schema already documents most parameters well. The description adds value by summarizing the filter dimensions and clarifying the return shape (compact record with title, budget, expenditure, SDGs, donors). It also adds behavioral context for the query parameter (searches every project, costs extra requests) that goes beyond the schema. The description doesn't need to repeat each parameter since the schema is rich.

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 ('Search'), a resource ('UNDP projects'), and the key filtering dimensions (year, country, SDG, focus area, signature solution, budget source, policy marker). It also explicitly distinguishes itself from undp_get_project by noting it returns a compact record per project while the sibling provides full detail. This is a clear, specific purpose that an agent can act on.

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 undp_get_project for full detail of one project, providing a clear alternative and the condition that selects it. It also explains pagination behavior ('follow next_offset for more'), which guides the agent on how to use the tool correctly. This is explicit 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.