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

Annotations indicate read-only, non-destructive, and idempotent behavior, which the description doesn't contradict. The description adds value by specifying what the tool returns (statistics like min, max, mean, median, ranking, top and bottom municipalities) and its use case (benchmarking and comparisons), which goes beyond the annotations. However, it doesn't mention potential limitations like rate limits or authentication needs, though annotations cover some safety aspects.

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

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

The description is concise and front-loaded, stating the core functionality in the first sentence and adding context in the second. It uses two sentences efficiently without unnecessary details. However, it could be slightly more structured by explicitly separating purpose from usage, but it's still well-organized and to the point.

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 complexity (6 parameters, no output schema) and rich annotations, the description is fairly complete. It explains what the tool does and its use case, but doesn't detail the output format or potential errors. With annotations covering safety and idempotency, and schema covering parameters, the description adds sufficient context, though it could benefit from mentioning the lack of an output schema or example outputs.

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 100% description coverage, providing clear details for all parameters (e.g., kpi_id, year, gender, municipality_type, top_n, bottom_n). The description doesn't add any parameter-specific information beyond what's in the schema, such as explaining parameter interactions or default behaviors. With high schema coverage, the baseline is 3, as the schema does the heavy lifting.

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's purpose: analyzing a KPI across municipalities with statistics (min, max, mean, median) and ranking, showing top and bottom municipalities. It specifies the resource (KPI across municipalities) and the action (analyze with statistics and ranking). However, it doesn't explicitly differentiate from sibling tools like 'compare_kpis' or 'get_kpi_data', which might offer similar functionality, so it's not a perfect 5.

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

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

The description implies usage for benchmarking and comparisons, suggesting when to use it (for performance analysis across municipalities). However, it doesn't provide explicit guidance on when to choose this tool over alternatives like 'compare_kpis' or 'filter_municipalities_by_kpi', nor does it mention any exclusions or prerequisites. The guidance is 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?

Annotations already provide safety information (readOnlyHint: true, destructiveHint: false, idempotentHint: true), so the bar is lower. The description adds valuable context beyond annotations: it explains the interpretation of correlation values ('Värden nära 1 = starkt positivt samband...' - values near 1 = strong positive relationship...), which helps the agent understand output semantics. It doesn't mention rate limits or authentication needs, but with good annotation coverage, this is sufficient.

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 appropriately sized and front-loaded: the first sentence states the core purpose, followed by an example and interpretation guidance. Every sentence adds value (clarifying the statistical method, providing a concrete use case, explaining result interpretation). It could be slightly more structured but remains efficient.

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 complexity (statistical correlation with 5 parameters) and rich schema/annotations (100% coverage, clear enums, safety hints), the description is reasonably complete. It explains what the tool does and how to interpret results. The main gap is no output schema, but the description compensates by explaining correlation value semantics. It doesn't cover all edge cases but provides enough for basic use.

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

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

Schema description coverage is 100%, with all parameters well-documented in the schema (e.g., 'gender' with enum descriptions). The description doesn't add any parameter-specific information beyond what the schema provides. According to guidelines, when schema coverage is high (>80%), the baseline score is 3 even without param info in the description.

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's purpose: 'Beräkna Pearson-korrelation mellan två KPIs' (Calculate Pearson correlation between two KPIs). It specifies the exact statistical method (Pearson correlation) and resource (KPIs), distinguishing it from siblings like 'get_kpi' (retrieval) or 'analyze_kpi_across_municipalities' (different analysis scope). The example further clarifies the application domain.

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 usage context through the example ('T.ex. korrelation mellan lärartäthet och skolresultat' - e.g., correlation between teacher density and school results), suggesting it's for exploring relationships between metrics. However, it doesn't explicitly state when to use this tool versus alternatives like 'get_kpi_trend' (trend analysis) or 'compare_municipalities' (geographic comparison), nor does it mention prerequisites or exclusions.

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

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

The annotations already provide comprehensive behavioral information: read-only, non-destructive, idempotent, and closed-world. The description adds some useful context about gender filtering options (T/M/K/all) and the benchmarking use case, but doesn't provide additional behavioral details like rate limits, authentication needs, or what specific data format is returned. With good annotation coverage, the description adds moderate value.

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 extremely concise - just two sentences that efficiently convey the core functionality, use case, and a key feature (gender filtering). Every word earns its place with no redundancy or unnecessary elaboration. The information is front-loaded with the main purpose stated 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 read-only comparison tool with comprehensive annotations and full schema coverage, the description provides adequate context. It explains the core purpose, mentions the benchmarking use case, and highlights gender filtering. The main gap is the lack of output schema, so the description doesn't indicate what format the comparison results will be returned in, but given the tool's relative simplicity and good annotation coverage, this is a minor limitation.

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 100% schema description coverage, all parameters are well-documented in the schema itself. The description mentions gender filtering (T/M/K) which aligns with the 'gender' parameter's enum values, but doesn't add significant semantic information beyond what's already in the schema descriptions. The baseline of 3 is appropriate when the schema does the heavy lifting for 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 clearly states the tool's purpose: comparing a specific key figure (KPI) across multiple municipalities for given years, with gender filtering. It uses specific verbs ('jämför' - compare) and resources ('nyckeltal' - key figure, 'kommuner' - municipalities). However, it doesn't explicitly distinguish this tool from its many siblings like 'analyze_kpi_across_municipalities' or 'compare_kpis', which appear similar in function.

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 some usage context by stating it's 'excellent for benchmarking' and supports gender filtering, which implies when this tool might be appropriate. However, it doesn't explicitly state when to use this tool versus alternatives like 'analyze_kpi_across_municipalities' or 'compare_kpis', nor does it mention any prerequisites or exclusions. The guidance is 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?

Annotations already provide key behavioral hints (read-only, non-destructive, idempotent, closed-world). The description adds minimal behavioral context beyond this, mentioning the filtering action and usefulness but not detailing aspects like performance, rate limits, or error conditions. With annotations covering safety, the description adds some value but not rich behavioral 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?

The description is efficiently structured in two sentences: the first states the core function with concrete examples, and the second explains the utility. Every word contributes meaning without redundancy, and it's front-loaded with the main action. This is a model of concise, well-structured tool description.

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 moderate complexity (6 parameters, filtering logic) and rich annotations, the description is reasonably complete. It clarifies the tool's purpose and usage context. However, without an output schema, it doesn't describe return values (e.g., list format, data included), leaving a minor gap. For a read-only filtering tool, it's mostly adequate.

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

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

Schema description coverage is 100%, with each parameter well-documented in the schema (e.g., operator enum meanings, gender codes). The description doesn't add parameter-specific details beyond what the schema provides, though it reinforces the tool's purpose with examples. Given high schema coverage, the baseline score of 3 is appropriate.

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

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

The description clearly states the tool's purpose: filtering municipalities based on KPI threshold values. It provides specific examples ('lärartäthet > 12' and 'arbetslöshet < 5%') and mentions the outcome ('identifiera kommuner som uppfyller specifika kriterier'). However, it doesn't explicitly differentiate this filtering tool from similar sibling tools like 'search_municipalities' or 'get_municipality_kpis', which prevents a perfect score.

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 usage context through examples ('Användbart för att identifiera kommuner...'), suggesting it's for finding municipalities meeting specific criteria. However, it lacks explicit guidance on when to use this tool versus alternatives like 'search_municipalities' or 'compare_municipalities', and doesn't mention prerequisites or exclusions. The guidance is present but not comprehensive.

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

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

Annotations already provide readOnlyHint=true, destructiveHint=false, idempotentHint=true, and openWorldHint=false, covering safety and idempotency. The description adds value by specifying the return content ('fullständig metadata inklusive publiceringsdatum och könsuppdelning' - 'complete metadata including publication date and gender breakdown'), which isn't covered by annotations. However, it doesn't mention potential errors (e.g., invalid ID), rate limits, or authentication needs, leaving some behavioral aspects uncovered.

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 concise sentences in Swedish, front-loaded with the core purpose and followed by return details. Every word earns its place with no redundancy or fluff, making it highly efficient and well-structured for quick comprehension.

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

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

Given the tool's simplicity (1 parameter, 100% schema coverage, rich annotations), the description is mostly complete. It clarifies the return content, which compensates for the lack of an output schema. However, it could slightly improve by hinting at error cases or linking to siblings, but overall it's adequate for this low-complexity 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 description coverage is 100% with a single parameter 'kpi_id' fully documented in the schema. The description doesn't add any parameter-specific details beyond what's in the schema (e.g., format examples beyond 't.ex. "N15033"'), so it meets the baseline of 3 where the schema does the heavy lifting without extra value from the description.

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 specific action ('Hämta detaljerad information' - 'Retrieve detailed information') and resource ('om ett specifikt nyckeltal (KPI) via dess ID' - 'about a specific key performance indicator (KPI) via its ID'), distinguishing it from siblings like get_kpis (plural) or get_kpi_data (which might return different data). The Swedish text is precise and unambiguous.

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

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

The description implies usage context by specifying it retrieves details for a specific KPI via ID, suggesting it should be used when you have a known KPI identifier rather than for searching or listing. However, it doesn't explicitly state when NOT to use it or name alternatives like get_kpis (for listing) or search_kpis (for searching), leaving some room for improvement in sibling differentiation.

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

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

Annotations already provide strong behavioral hints (readOnlyHint: true, destructiveHint: false, idempotentHint: true, openWorldHint: false). The description adds valuable context beyond this: it specifies that data is 'faktiska' (actual/real) values, clarifies gender filter semantics (T=Totalt, M=Män, K=Kvinnor), and mentions the municipal/organizational unit scope. This enhances understanding without contradicting annotations.

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

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

The description is efficiently structured in two sentences: the first states the core purpose, the second adds filtering capabilities. Every word earns its place with no redundancy, and key information (purpose, filters) is front-loaded appropriately for a tool with clear annotations and schema.

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

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

Given the tool's moderate complexity (5 parameters, 1 required), rich annotations (covering safety and idempotency), and full schema coverage, the description provides adequate context. It clarifies data nature ('faktiska') and filter semantics, though without an output schema, it doesn't describe return format or pagination—a minor gap for a read-only data retrieval 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?

With 100% schema description coverage, the input schema already documents all 5 parameters thoroughly (including the exclusive choice between municipality_id and ou_id, and gender enum meanings). The description adds minimal parameter semantics beyond the schema—only clarifying gender codes—so it meets but doesn't exceed the baseline for high schema 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 states the tool's purpose: 'Hämta faktiska KPI-datavärden för specifika kommuner eller organisationsenheter' (Retrieve actual KPI data values for specific municipalities or organizational units). It specifies the verb (retrieve), resource (KPI data values), and target scope (municipalities/organizational units). However, it doesn't explicitly differentiate from siblings like 'get_kpi' or 'get_kpis', which might retrieve different scopes of KPI data.

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 usage context by mentioning filtering capabilities ('Kan filtrera efter år och kön'), but doesn't provide explicit guidance on when to use this tool versus alternatives like 'get_kpi' or 'compare_kpis'. It lacks statements about prerequisites, exclusions, or named alternatives, leaving usage decisions to inference from the 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?

Annotations already provide strong behavioral hints (readOnlyHint: true, destructiveHint: false, idempotentHint: true, openWorldHint: false). The description adds value by specifying the output includes 'alla ingående nyckeltal' (all included key figures), which gives context about what information is returned. However, it doesn't disclose additional behavioral traits like rate limits, authentication needs, or error conditions beyond what annotations cover.

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 appropriately concise with two sentences that each serve a purpose: the first states the core functionality, and the second provides usage context. It's front-loaded with the main purpose. There's minimal waste, though the second sentence could be slightly more specific about the exploration context.

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 low complexity (single parameter, no output schema), the description combined with rich annotations (readOnly, idempotent, etc.) provides adequate context. The description specifies what information is returned (KPI group details with all key figures), which compensates for the lack of output schema. For a simple read operation, this is reasonably complete, though it could benefit from mentioning response format or error cases.

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

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

Schema description coverage is 100% with a single parameter 'group_id' clearly documented. The description doesn't add any parameter-specific information beyond what's in the schema (e.g., format examples, constraints, or relationships). With complete schema coverage, the baseline score of 3 is appropriate as the description doesn't compensate but also doesn't need to given the schema's completeness.

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 action ('Hämta detaljerad information' - Get detailed information) and resource ('om en specifik KPI-grupp' - about a specific KPI group). It specifies the scope includes 'alla ingående nyckeltal' (all included key figures), which helps distinguish it from sibling tools like 'get_kpi_groups' (likely listing groups) or 'get_kpi' (single KPI). However, it doesn't explicitly differentiate from 'get_kpi_data' or 'get_kpis_by_operating_area' which might overlap in purpose.

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 some usage context with 'Användbar för att utforska relaterade KPIs' (Useful for exploring related KPIs), which implies when this tool is appropriate. However, it doesn't explicitly state when to use this vs. alternatives like 'get_kpi_groups' (for listing groups) or 'get_kpi' (for single KPI details). No exclusions or prerequisites are mentioned, leaving usage somewhat 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?

Annotations already declare this as a read-only, non-destructive, idempotent operation with closed-world data. The description adds useful context about what KPI groups are ('tematiska samlingar av nyckeltal') and their organizational purpose, which helps the agent understand the semantic context beyond the technical safety profile. No contradiction with annotations exists.

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 efficiently structured in two sentences. The first sentence states the core functionality with optional search, and the second sentence provides helpful context about what KPI groups are and their purpose. Every sentence earns its place with no wasted words.

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 read operation with comprehensive annotations and full parameter documentation, the description provides adequate context. It explains what KPI groups are and their organizational role, which helps the agent understand the semantic domain. The main gap is the lack of output schema, but the description compensates reasonably given the tool's simplicity.

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 100% description coverage, with the single parameter 'query' fully documented in the schema. The description mentions 'valfri sökning' (optional search) which aligns with the schema but doesn't add meaningful semantic context beyond what's already in the structured data. This meets the baseline for high schema 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 states the tool's purpose: 'Lista KPI-grupper' (List KPI groups) with optional search functionality. It explains that groups are thematic collections of KPIs that help organize them by topic. However, it doesn't explicitly differentiate this tool from its sibling 'get_kpi_group' (singular vs. plural), which would be needed for a score of 5.

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

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

The description implies usage context by mentioning 'valfri sökning' (optional search) and explaining the organizational purpose of KPI groups. However, it doesn't provide explicit guidance on when to use this tool versus alternatives like 'get_kpi_group' (singular) or 'search_kpis', nor does it mention any exclusions or prerequisites.

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

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

Annotations provide readOnlyHint=true, destructiveHint=false, idempotentHint=true, and openWorldHint=false, covering safety and idempotency. The description adds context about the batch size limit (up to 25 KPI IDs per call), which is useful behavioral information not in the annotations. However, it doesn't describe response format, error handling, or other traits like rate limits. With annotations covering core traits, the description adds some value but not rich behavioral 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 description is two sentences, front-loaded with the core purpose and followed by a constraint. Every word earns its place: the first sentence defines the action and resource, the second specifies the batch limit. There's no redundancy or fluff, making it appropriately sized and efficient.

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 low complexity (one parameter, read-only operation), rich annotations (covering safety and idempotency), and 100% schema coverage, the description is reasonably complete. It adds the batch size context, which is helpful. However, without an output schema, it doesn't describe return values (e.g., format of retrieved KPIs), leaving a minor gap. For this simple tool, it's mostly adequate.

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 100% description coverage, with the 'kpi_ids' parameter fully documented in the schema (array of strings, min 1, max 25 items). The description mentions 'Accepterar upp till 25 KPI-ID:n per anrop' (Accepts up to 25 KPI IDs per call), which aligns with but doesn't add meaning beyond the schema. With high schema coverage, the baseline is 3, and the description doesn't compensate with additional semantics.

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's purpose: 'Hämta flera nyckeltal (KPIs) via deras ID:n i en enda förfrågan' (Retrieve multiple key performance indicators (KPIs) via their IDs in a single request). It specifies the verb ('hämta' - retrieve) and resource ('nyckeltal/KPIs'), but doesn't explicitly differentiate from siblings like 'get_kpi' (singular) or 'get_kpi_data' beyond the batch aspect. The description is clear but lacks explicit 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 implies usage context: when you need to retrieve multiple KPIs by their IDs in one call, with a limit of 25 IDs. However, it doesn't explicitly state when to use this tool versus alternatives like 'get_kpi' (for single KPI) or 'get_kpi_data' (which might have different parameters). The guidance is implied but not explicit about alternatives or exclusions.

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

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

Annotations already provide readOnlyHint=true, destructiveHint=false, idempotentHint=true, and openWorldHint=false, covering safety and idempotency. The description adds useful context about it being 'Enklare än fritextsökning' (simpler than free-text search), which helps set expectations, but doesn't disclose additional behavioral traits like rate limits, authentication needs, or pagination details.

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 appropriately sized with three concise sentences that are front-loaded: the first states the core purpose, the second gives examples, and the third explains the advantage. Every sentence earns its place by adding clarity and differentiation without redundancy.

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 low complexity (2 parameters, 100% schema coverage, no output schema) and rich annotations, the description is mostly complete. It covers purpose, usage context, and differentiation. However, it could slightly improve by hinting at the return format or data structure, though annotations help mitigate this gap.

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

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

Schema description coverage is 100%, with clear descriptions for both parameters (operating_area and limit). The description adds minimal value beyond the schema by giving examples ('Utbildning', 'Vård') and mentioning it returns 'alla KPIs' (all KPIs), but doesn't provide additional syntax, format details, or constraints. Baseline 3 is appropriate given the comprehensive schema.

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

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

The description clearly states the tool's purpose with a specific verb ('Hämta' - Get) and resource ('alla KPIs' - all KPIs), and distinguishes it from siblings by specifying filtering by operating area. It explicitly contrasts with 'fritextsökning' (free-text search), helping differentiate from tools like search_kpis.

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 clear context for when to use this tool: to find KPIs within a specific operating area like 'Utbildning' or 'Vård'. It mentions this is simpler than free-text search, implying an alternative, but doesn't explicitly name when-not-to-use scenarios or specific sibling alternatives beyond the general contrast.

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

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

Annotations already provide clear behavioral hints: readOnlyHint=true, destructiveHint=false, idempotentHint=true, openWorldHint=false. The description adds minimal behavioral context beyond this - it mentions gender filtering support ('Stöder könsfiltrering') which is useful but doesn't describe rate limits, authentication needs, or data format. With comprehensive annotations, the description adds some value but not rich behavioral 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?

The description is appropriately concise with three sentences that each serve a purpose: stating the core function, suggesting usage context, and mentioning a key feature (gender filtering). It's front-loaded with the main purpose. While efficient, the Swedish language might create minor accessibility issues for non-Swedish speaking agents.

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 moderate complexity (5 parameters, 3 required), comprehensive annotations, and 100% schema coverage, the description is adequate but not complete. It doesn't explain the return format (no output schema exists), data granularity, or potential limitations. For a trend analysis tool, more context about the nature of the returned trend data would be helpful.

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

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

Schema description coverage is 100%, with all parameters well-documented in the schema. The description mentions gender filtering ('Stöder könsfiltrering (T/M/K)') which aligns with the 'gender' parameter enum, but doesn't add meaningful semantic context beyond what the schema already provides. The baseline of 3 is appropriate when the schema does the heavy lifting.

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's purpose: 'Hämta historisk trenddata för ett nyckeltal som visar förändringar över tid' (Retrieve historical trend data for a key performance indicator showing changes over time). It specifies the verb ('Hämta' - retrieve) and resource ('historisk trenddata för ett nyckeltal' - historical trend data for a KPI). However, it doesn't explicitly differentiate from siblings like 'get_kpi' or 'get_kpi_data', which likely retrieve different types of KPI data.

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 implied usage context: 'Användbart för att analysera utveckling och identifiera trender' (Useful for analyzing development and identifying trends). This suggests when the tool is appropriate, but it doesn't explicitly state when to use this vs. alternatives like 'get_kpi' (which might retrieve current values) or 'analyze_kpi_across_municipalities' (which might compare across locations). No explicit exclusions or prerequisites are mentioned.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false, idempotentHint=true, and openWorldHint=false, covering safety and idempotency. The description adds the ID format constraint (4-digit codes with examples) and clarifies it's for detailed information, which provides useful context beyond annotations. However, it doesn't describe return format or error behavior.

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 concise sentences: first states purpose, second provides ID format with concrete examples. No wasted words, front-loaded with the core function. Every sentence earns its place by adding necessary context.

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 read operation with good annotations (safe, idempotent) and a single well-documented parameter, the description is reasonably complete. It lacks output schema, so doesn't describe return values, but given the tool's simplicity and annotation coverage, this is a minor gap. Sibling context is handled implicitly through specificity.

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

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

Schema description coverage is 100%, with the parameter fully documented in the schema. The description reinforces the ID format with examples ('0180' for Stockholm, '1480' for Göteborg), adding minor value but not significant semantics beyond the schema. Baseline 3 is appropriate given high schema 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 states the verb ('Hämta' - Get/Retrieve) and resource ('detaljerad information om en specifik kommun' - detailed information about a specific municipality), specifying it's for a specific municipality via ID. It distinguishes from siblings like 'search_municipalities' (which likely searches) and 'get_municipality_kpis' (which gets KPIs rather than general details).

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 clear context: use when you need detailed information about a specific municipality identified by its 4-digit ID. It doesn't explicitly state when NOT to use it or name alternatives, but the specificity (vs. search or KPI-focused tools) implies usage boundaries.

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

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

Annotations already provide readOnlyHint=true, destructiveHint=false, idempotentHint=true, and openWorldHint=false, covering safety and idempotency. The description adds minimal behavioral context beyond this - it mentions retrieving 'detaljerad information' (detailed information) and that it's useful for analysis, but doesn't specify what 'detailed information' includes, response format, or any rate limits. With good annotation coverage, the bar is lower, and the description adds some value but not rich behavioral 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?

The description is appropriately concise with two sentences. The first sentence states the core purpose, and the second provides usage context. Both sentences earn their place, though the second could be more specific. No wasted words or redundancy.

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 has good annotations (read-only, idempotent, non-destructive) and 100% schema coverage for its single parameter, the description is moderately complete. However, with no output schema, the description doesn't explain what 'detaljerad information' (detailed information) includes in the response. For a retrieval tool, more detail about the return structure would be helpful, though annotations cover the safety profile adequately.

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

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

Schema description coverage is 100% with one parameter 'group_id' clearly documented as 'Kommungrupp-ID' (Municipality group ID). The description doesn't add any parameter semantics beyond what the schema provides - it mentions retrieving information about a 'specifik kommungrupp' (specific municipality group) which aligns with the parameter but doesn't provide additional context about valid IDs, format, or examples. Baseline is 3 when schema does the heavy lifting.

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's purpose: 'Hämta detaljerad information om en specifik kommungrupp inklusive alla medlemskommuner' (Retrieve detailed information about a specific municipality group including all member municipalities). It specifies the verb ('Hämta' - retrieve) and resource ('kommungrupp' - municipality group), but doesn't explicitly differentiate from sibling tools like 'get_municipality_groups' which likely lists groups rather than details of a specific group.

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 some usage context: 'Användbar för att analysera grupper av liknande kommuner' (Useful for analyzing groups of similar municipalities). This implies when to use it (for analysis of similar municipalities), but doesn't explicitly state when NOT to use it or mention alternatives like 'get_municipality_groups' for listing groups or 'get_municipality' for individual municipality 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?

Annotations cover key behavioral traits (read-only, non-destructive, idempotent, closed-world), so the bar is lower. The description adds context about the purpose of groups (for comparing similar municipalities), which is useful but doesn't disclose additional behaviors like rate limits, auth needs, or output format. It doesn't contradict annotations, so a baseline score is appropriate given the annotation coverage.

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 with two sentences that directly state the tool's purpose and utility. It's front-loaded with the main action ('Lista kommungrupper') and avoids unnecessary details. However, it could be slightly more structured by explicitly separating purpose from usage guidance.

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

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

Given the tool's low complexity (1 optional parameter, no output schema) and rich annotations, the description is minimally adequate. It covers the basic purpose and hints at usage but lacks details on output format, error handling, or examples. For a simple read-only tool, it meets minimum requirements but could be more complete for agent usability.

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

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

Schema description coverage is 100%, with the 'query' parameter documented as 'Sökterm för att filtrera grupper efter titel' (Search term to filter groups by title). The description doesn't add any parameter-specific details beyond this, such as examples or constraints. With high schema coverage, the baseline score of 3 is justified as the schema handles the heavy lifting.

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's purpose: 'Lista kommungrupper' (list municipality groups) and provides examples like 'storstadsregioner, kustkommuner etc.' (metropolitan regions, coastal municipalities, etc.). It distinguishes from siblings by focusing on groups rather than individual municipalities or KPIs, though it doesn't explicitly name alternatives. The purpose is specific but could be more precise about 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 implies usage context by stating 'Grupper hjälper till att jämföra liknande kommuner' (Groups help to compare similar municipalities), suggesting this tool is for grouping municipalities for comparison. However, it lacks explicit guidance on when to use this versus siblings like 'compare_municipalities' or 'get_municipality_group', and no exclusions are provided. Usage is implied but not clearly defined.

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

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

Annotations cover read-only, non-destructive, and idempotent behavior, but the description adds valuable context: it mentions 'Snabb och pålitlig - använder cachad KPI-katalog' (Fast and reliable - uses cached KPI catalog), which informs about performance and data freshness. This goes beyond annotations, though it doesn't detail rate limits or error 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 concise and front-loaded with the core purpose. The second sentence adds filtering context, and the third provides behavioral insight (cached catalog). All sentences contribute value without redundancy, though it could be slightly more structured for clarity.

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

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

Given the tool's moderate complexity (3 parameters, 1 required), rich annotations, and 100% schema coverage, the description is fairly complete. It adds caching context and references a sibling tool ('list_operating_areas'). However, without an output schema, it doesn't describe return values or pagination, leaving a minor gap.

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

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

Schema description coverage is 100%, so parameters are well-documented in the schema. The description adds minimal semantics by mentioning filtering by operating area and implying the tool retrieves KPIs, but it doesn't provide additional details like parameter interactions or usage examples beyond what's 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 clearly states the tool's purpose: 'Visa tillgängliga KPIs för en kommun' (Show available KPIs for a municipality). It specifies the resource (KPIs) and action (show/retrieve) and mentions filtering by operating area. However, it doesn't explicitly differentiate from siblings like 'get_kpis_by_operating_area' or 'get_kpis', which have overlapping 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 implies usage context by mentioning filtering by operating area and referencing 'list_operating_areas' for available options. It doesn't provide explicit guidance on when to use this tool versus alternatives like 'get_kpis_by_operating_area' or 'get_kpis', nor does it specify exclusions or prerequisites beyond the required municipality_id.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false, idempotentHint=true, and openWorldHint=false, covering safety and idempotency. The description adds minimal behavioral context beyond this, only specifying that it retrieves detailed information via ID. No additional behavioral traits like rate limits, authentication needs, or error conditions are 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 a single, efficient sentence that directly states the tool's purpose without any unnecessary words. It's appropriately sized and front-loaded, making it easy to understand quickly.

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

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

Given the tool's simplicity (1 parameter, 100% schema coverage, annotations covering safety), the description is minimally adequate. However, with no output schema, it doesn't explain what 'detailed information' includes, leaving gaps in understanding the return values. For a read-only tool with good annotations, this is acceptable but not comprehensive.

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

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

Schema description coverage is 100%, with the parameter 'ou_id' fully documented in the schema. The description adds no additional meaning about the parameter beyond implying it's used to identify a specific organizational unit, which is already clear from the schema. Baseline 3 is appropriate when schema coverage is high.

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 ('Hämta detaljerad information' - 'Get detailed information') and resource ('en specifik organisationsenhet' - 'a specific organizational unit'), making the purpose unambiguous. However, it doesn't explicitly differentiate from sibling tools like 'search_organizational_units' or 'get_ou_types', which would require a 5.

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

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

The description provides no guidance on when to use this tool versus alternatives like 'search_organizational_units' or 'get_ou_types'. It mentions retrieving by ID but doesn't specify prerequisites or when this approach is appropriate versus searching.

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

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

The description adds valuable context beyond annotations: it specifies that the tool returns 'vanliga' (common) types with descriptions and provides concrete examples of the output format. Annotations already indicate read-only, non-destructive, idempotent behavior with a closed world, so the description appropriately focuses on what data is returned rather than repeating safety characteristics.

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, efficient sentence that immediately states the tool's purpose and provides helpful examples. Every element earns its place: the core functionality is stated first, followed by illustrative examples that clarify the output format without unnecessary elaboration.

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 read-only lookup tool with no parameters and comprehensive annotations, the description is reasonably complete. It explains what data is returned and provides examples, though it could benefit from mentioning whether the list is static/cached or dynamic, and clarifying the relationship to sibling organizational unit tools. The absence of an output schema makes the example particularly valuable.

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 parameters and 100% schema description coverage, the baseline is 4. The description appropriately doesn't discuss parameters since none exist, and instead focuses on what the tool returns. It provides semantic context about the output being a list of common types with descriptions and examples.

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's purpose: 'Hämta en lista över vanliga organisationsenhetstyper och deras beskrivningar' (Get a list of common organizational unit types and their descriptions). It specifies the verb ('Hämta' - Get) and resource ('organisationsenhetstyper' - organizational unit types), though it doesn't explicitly differentiate from siblings like 'get_organizational_unit' or 'search_organizational_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?

The description provides no guidance on when to use this tool versus alternatives. It doesn't mention sibling tools like 'get_organizational_unit' or 'search_organizational_units', nor does it specify use cases or exclusions. The example given ('t.ex. V11=Förskola, V15=Grundskola') illustrates output format but doesn't guide usage decisions.

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

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

Annotations already indicate this is a safe, read-only, idempotent operation. The description adds useful context about what information is returned (operating areas with KPI counts) and the purpose (overview of available data types), which helps the agent understand the tool's behavior beyond the annotations.

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

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

Two concise sentences that efficiently convey the tool's purpose and value. The first sentence states what it does, the second explains why it's useful. No wasted words or redundant information.

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

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

For a zero-parameter read-only tool with comprehensive annotations, the description provides adequate context about what information is returned. However, without an output schema, it could benefit from more detail about the return format (e.g., structure of operating area objects).

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 parameters and 100% schema description coverage, the baseline is 4. The description appropriately doesn't discuss parameters since none exist, focusing instead on what the tool returns.

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 lists operating areas with KPI counts, providing an overview of available data types. It uses specific verbs ('Lista alla') and resources ('verksamhetsområden'), but doesn't explicitly differentiate from sibling tools like 'get_kpis_by_operating_area'.

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 provided on when to use this tool versus alternatives. The description mentions it gives an overview of available data types, but doesn't specify use cases or contrast with sibling tools that might also provide operating area information.

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

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

Annotations already indicate this is a read-only, non-destructive, idempotent operation with a closed-world assumption. The description adds value by specifying that it returns a list and that Swedish terms work best, which are behavioral traits not covered by annotations. However, it doesn't mention pagination, rate limits, or authentication needs, leaving some gaps in behavioral 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 description is concise and front-loaded, consisting of two sentences that efficiently convey the tool's purpose and a key usage tip (Swedish terms). Every sentence adds value without redundancy, making it easy for an AI agent to parse quickly.

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 moderate complexity (search with multiple filters), rich annotations (covering safety and idempotency), and full schema coverage, the description is reasonably complete. It specifies the return type (list) and a language preference, though without an output schema, it could benefit from more detail on result structure. However, it adequately complements the structured data for agent use.

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

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

Schema description coverage is 100%, with each parameter well-documented in the input schema. The description adds minimal semantic value beyond the schema, only reinforcing that Swedish terms are best for the query parameter. Since the schema does the heavy lifting, the baseline score of 3 is appropriate, as the description doesn't significantly enhance parameter understanding.

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 searches for KPIs using free-text, publication date, or operating area filters and returns a list of matching KPIs. It specifies the verb 'search' and resource 'KPIs' with filtering methods, but doesn't explicitly differentiate from sibling tools like 'get_kpis' or 'search_municipalities' beyond mentioning Swedish terms work best.

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

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

The description implies usage through its filtering options (free-text, date, area) and notes that Swedish search terms yield best results, providing some context. However, it doesn't explicitly state when to use this tool versus alternatives like 'get_kpis' (which might fetch all KPIs without filtering) or 'search_municipalities' (which searches a different resource). No explicit exclusions or alternatives are named.

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

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

Annotations already provide readOnlyHint=true, openWorldHint=false, idempotentHint=true, and destructiveHint=false, covering safety and idempotency. The description adds valuable context by specifying the dataset scope (290 municipalities, 21 regions in Sweden) and filtering capabilities, which helps the agent understand the tool's behavior beyond the annotations.

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

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

The description is efficiently structured in two sentences: the first states the purpose and filtering options, the second provides dataset context. Every sentence adds value without redundancy, making it appropriately sized and 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?

Given the tool's low complexity (2 parameters, no output schema) and rich annotations, the description is reasonably complete. It covers purpose, filtering, and dataset scope. However, it could slightly improve by hinting at output format or when to use versus specific retrieval tools, though annotations mitigate some gaps.

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

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

Schema description coverage is 100%, with clear descriptions for both parameters (query for name filtering, municipality_type with enum values). The description mentions filtering by name or type, aligning with the schema but not adding significant extra meaning. Baseline 3 is appropriate since the schema already documents parameters well.

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 searches for Swedish municipalities or regions with filtering by name or type, providing a specific verb ('Sök') and resource ('svenska kommuner eller regioner'). It distinguishes from most siblings by focusing on search rather than KPI analysis or direct retrieval, though it doesn't explicitly differentiate from 'filter_municipalities_by_kpi' or 'search_organizational_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?

The description implies usage context by mentioning filtering by name or type and providing counts (290 municipalities, 21 regions), suggesting it's for broad searches. However, it doesn't explicitly state when to use this tool versus alternatives like 'get_municipality' (for specific retrieval) or 'filter_municipalities_by_kpi' (for KPI-based filtering), leaving some ambiguity.

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

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

The description adds valuable behavioral context beyond annotations: it warns about result truncation to a limit (max 100) and advises checking the 'truncated' field in the response. Annotations cover read-only, non-destructive, and idempotent aspects, but the description provides practical usage details not in the structured data.

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

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

The description is concise and well-structured: two sentences that efficiently state the purpose, filtering options, and a critical behavioral note about truncation. Every sentence adds value without redundancy.

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 complexity (search with filtering), rich annotations, and full schema coverage, the description is mostly complete. It lacks an output schema, but the description hints at response structure ('truncated' field). It could be more explicit about return format, but it covers key usage aspects adequately.

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 fully documents all parameters. The description mentions filtering by name, municipality, or type, which aligns with the schema but does not add significant semantic value beyond it. Baseline score of 3 is appropriate as the schema handles 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 clearly states the tool's purpose: 'Sök efter organisationsenheter' (search for organizational units) with specific examples like schools, preschools, and elderly homes. It distinguishes from siblings by focusing on organizational units rather than KPIs or municipalities, which are covered by other tools like search_kpis and search_municipalities.

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 clear context for when to use this tool: to search for organizational units with filtering options. However, it does not explicitly state when not to use it or name specific alternatives, though the sibling tools suggest alternatives for KPI or municipality searches.

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