Server Quality Checklist

Tool Scores

• describe_flowC
  2.6/5.0
  Behavior2/5

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

  No annotations are provided, so the description carries the full burden of behavioral disclosure. It reveals what the tool returns (dimensions, code counts, sample) but does not state whether it is read-only, whether it requires special permissions, or what side effects or limitations exist. The word 'describe' weakly implies a safe read operation, but this is not explicit.

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

  Conciseness4/5

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

  The description is one short sentence with no filler words; it front-loads the core output content. It is concise but perhaps too sparse to fully serve as a standalone definition, though no sentence is wasted.

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

  Completeness2/5

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

  With two required string parameters, no annotations, no output schema, and no param guidance, the description leaves critical gaps: what counts as a 'flow', how 'provider' should be specified, and what the 'short sample' contains. The description gives a rough idea of the tool's purpose but not enough detail for an agent to call it confidently.

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

  Parameters1/5

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

  Schema description coverage is 0% for both required parameters, and the description adds no meaning for 'provider' or 'flow'. It does not explain their format, possible values, or how they identify a dataflow. The description fails to compensate for the lack of schema-level documentation.

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

  Purpose4/5

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

  The description names the resource ('dataflow') and states the specific output content: dimensions, code counts, and a short sample. Although it is a noun fragment rather than a verb phrase, the tool name 'describe_flow' makes the operation clear. It does not explicitly distinguish itself from siblings like fetch_data or find_dataflows, so it stops short of a 5.

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

  Usage Guidelines2/5

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

  There is no guidance on when to use this tool versus alternatives such as find_dataflows, fetch_data, or search_codes. The description only implies that this tool provides descriptive metadata rather than actual data, but it never states a usage scenario, prerequisites, or exclusions.

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

• entity_ownershipC
  2.7/5.0
  Behavior2/5

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

  No annotations are present, so the description carries the full burden of behavioral disclosure. It states the kind of data returned (parent/children relationships) but does not mention read-only semantics, failure behavior, required identifier format, or whether results can be empty.

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

  Conciseness4/5

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

  The description is a single concise phrase with no filler or redundant information. It is easy to parse, though it is slightly too terse to fully carry the behavioral and usage context.

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

  Completeness2/5

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

  With no output schema and no annotations, the description should explain more about the return shape and edge cases. It names the three relationship types but leaves the agent guessing about structure, null cases, or how multiple children are represented.

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

  Parameters2/5

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

  Schema description coverage is 0%, so the description must compensate. It mentions that the input is an LEI but adds no format, length, validation, or example details beyond the schema's 'lei' property. The single parameter is simple, but the description does not meaningfully extend the schema.

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

  Purpose4/5

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

  The description identifies a specific resource (ownership relationships) and the input (an LEI), naming the exact outputs: direct parent, ultimate parent, and direct children. It is not a tautology and is distinguishable from sibling tools like get_entity and find_entity, though it lacks an explicit verb such as 'get' or 'list'.

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

  Usage Guidelines2/5

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

  No guidance is provided about when to choose entity_ownership over siblings like get_entity or find_entity. The description offers no context for when an agent should prefer this tool for ownership information versus other entity-related tools.

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

• find_dataflowsC
  2.7/5.0
  Behavior2/5

  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 only states search by id or name, but does not disclose return behavior, pagination, limit semantics, or what happens with an empty search. The minimal wording gives little beyond the basic operation.

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

  Conciseness4/5

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

  The description is a single concise sentence with no filler. It is suitably front-loaded with the action and target. However, it could be slightly expanded to include useful behavioral or parameter details without losing conciseness.

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

  Completeness2/5

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

  With three parameters, no annotations, and no output schema, the description is too sparse. It omits return value details, limit semantics, and usage context. An agent would need to infer how to invoke the tool correctly, especially around the optional parameters.

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

  Parameters2/5

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

  Schema coverage is 0%, so the description must compensate. It clarifies that 'provider' scopes the search and that 'search' matches by id or name, but it does not explain the 'limit' parameter, default behavior, or search format (exact vs partial). This leaves significant parameter ambiguity.

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

  Purpose4/5

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

  The description states a specific verb and object: 'Search a provider's dataflows by id or name.' This clearly indicates the tool's function and differentiates it from siblings by the resource type. It does not explicitly distinguish from search_codes, but 'dataflows' is a distinct enough resource.

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

  Usage Guidelines2/5

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

  There is no guidance on when to prefer this tool over alternatives like search_codes or describe_flow. The description implies that it is used for searching dataflows, but it provides no explicit context, exclusions, or conditions.

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

• get_entityC
  2.7/5.0
  Behavior2/5

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

  With no annotations, the description must disclose behavioral traits, but 'look up one LEI' only implies a read operation. It does not say whether lookup is exact-match, what a successful response contains, or what happens for unknown LEIs.

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

  Conciseness4/5

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

  The description is a single, front-loaded sentence with no wasted words. It is concise, though the brevity comes at the cost of useful detail.

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

  Completeness2/5

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

  Given no output schema, no annotations, and several related sibling tools, this one-sentence description is incomplete. An agent cannot determine the return shape, exact-match behavior, or when to prefer get_entity over find_entity.

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

  Parameters2/5

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

  Schema coverage is 0%, so the description must clarify the lone lei parameter. It adds only the phrase 'one LEI', which restates the parameter name without explaining format, length, or expected value semantics.

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

  Purpose4/5

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

  The description uses a specific verb ('look up') and a concrete resource ('one LEI'), making the tool's core purpose clear. It does not differentiate itself from the sibling tool find_entity, so it stops short of a 5.

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

  Usage Guidelines2/5

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

  No guidance is provided on when to use get_entity instead of related siblings like find_entity or entity_ownership. There is no context, precondition, or alternative mentioned.

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

• compare_vintagesB
  3.2/5.0
  Behavior3/5

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

  With no annotations provided, the description carries the burden of disclosing behavior. It usefully explains the output structure: 'revisions' lists changed periods with the two vintages, and 'no_data' lists vintages missing the key. It does not disclose any side effects, auth requirements, or rate limits, but the tool appears to be a read operation.

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

  Conciseness5/5

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

  The description is short and front-loaded, with the core purpose stated first and the key output behaviors following. Every sentence contributes meaning, and there is no filler or repetition.

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

  Completeness2/5

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

  Given six parameters, no output schema, no annotations, and sibling tools with overlapping concerns, the description is not complete enough. It explains the response's revisions and no_data fields but leaves parameter usage, date filtering, limit behavior, and comparison with fetch_data or list_vintages unexplained.

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

  Parameters2/5

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

  Schema description coverage is 0%, and the description does not explain the six parameters beyond implying that 'key' is central to the comparison. Provider, flow, start, end, and limit semantics are left entirely to the schema, which lacks descriptions. This is a significant gap that the description does not compensate for.

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

  Purpose4/5

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

  The description clearly states that this tool reads one key across several vintages and describes the revisions between them. It conveys a specific operation and resource, though it could more explicitly differentiate itself from sibling tools like list_vintages or fetch_data.

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

  Usage Guidelines3/5

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

  The description implies the tool is for comparing values of a key across vintages, which gives a sense of when it applies. However, it provides no explicit guidance about when to prefer this over fetch_data or list_vintages, nor does it mention exclusions or alternatives.

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

• find_entityB
  3.3/5.0
  Behavior3/5

  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 useful context by warning that hits require country and status verification, implying name matches may not be unique or authoritative. However, it does not mention return shape, no-match behavior, or optional filter effects.

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

  Conciseness5/5

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

  The description is two short, purposeful sentences with no filler. The core search action is front-loaded, and the verification warning earns its place by giving agents actionable guidance.

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

  Completeness3/5

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

  The tool is relatively simple and the description covers its primary purpose and the most important safety nuance. Still, without an output schema, annotations, or parameter details, the agent is left to infer what country and limit mean and what the response contains.

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

  Parameters2/5

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

  Schema description coverage is 0%, so the description must compensate. It clarifies that the name parameter is a legal name, but says nothing about the limit or country parameters, including defaults or filtering semantics. This is a significant gap for a tool with three parameters.

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

  Purpose4/5

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

  The description states a specific action and resource: 'Search GLEIF by legal name.' This makes the tool's core purpose clear and distinguishes it from the sibling get_entity, which likely retrieves a specific known entity rather than searching by name.

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

  Usage Guidelines3/5

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

  The instruction to 'Verify country and status on every hit' conveys a key usage caveat, but the description does not explicitly say when this tool should be preferred over related siblings like get_entity or entity_ownership. The usage context 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.

• fx_period_rateB
  3.3/5.0
  Behavior3/5

  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 discloses that the return shape matches fetch_data and that dates follow ISO format, which is useful. It does not mention read-only behavior, authentication, pagination, or error handling, so the behavioral picture is incomplete.

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

  Conciseness5/5

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

  The description is three sentences with no filler: the convention mapping, date format, and return shape are each covered in one efficient sentence. It is well-structured and front-loads the most important usage guidance.

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

  Completeness3/5

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

  For a tool with no annotations, no output schema, and no parameter descriptions, the description provides key domain context and a useful link to fetch_data. However, it omits important details such as currency-code format, frequency/limit semantics, and explicit differentiation from fx_spot, so an agent might still make incorrect assumptions when calling it.

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

  Parameters2/5

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

  Schema description coverage is 0%, so the description must compensate. It explains the non-obvious 'convention' parameter and date format, but leaves currency, start, end, freq, and limit mostly to inference. For a six-parameter tool, this is not enough compensation for the missing schema descriptions.

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

  Purpose4/5

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

  The description identifies the tool as returning Euro reference rates and distinguishes between 'average' and 'end_of_period' conventions, which makes the resource and its main use concrete. It lacks an explicit verb phrase and does not directly contrast itself with fx_spot, but the purpose is still clear enough for an agent to separate it from spot-rate tools.

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

  Usage Guidelines3/5

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

  The description provides explicit convention guidance: use 'average' for flows and 'end_of_period' for stocks, and it specifies ISO date formatting. However, it does not explicitly say when to choose this tool over sibling tools like fx_spot or fetch_data, so tool-selection context 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.

• list_vintagesB
  3.3/5.0
  Behavior4/5

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

  With no annotations, the description carries the full burden of behavioral disclosure. It reveals ordering behavior ('oldest first, with the current flow last') and an important semantic distinction (vintage shows what was known at publication time, not later revisions). This goes beyond a bare 'list vintages' statement and materially helps an agent understand what response content to expect.

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

  Conciseness5/5

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

  Two concise sentences deliver the essential information with no fluff. The first sentence front-loads what the tool returns and its ordering; the second adds a crucial definition of 'vintage' that earns its place.

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

  Completeness3/5

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

  For a simple two-parameter list tool, the description covers the core concept and ordering well. However, it lacks any explanation of the provider and flow parameters, does not describe the return format or output fields, and provides no pointer to related tools. It is adequate but not fully complete.

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

  Parameters2/5

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

  Schema description coverage is 0%, so the description should compensate, but it only implicitly connects 'dataflow' to the 'flow' parameter. The 'provider' parameter is entirely unexplained, and no details about valid values, formats, or relationships between provider and flow are provided. This leaves a significant gap for correct invocation.

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

  Purpose4/5

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

  The description clearly states that the tool returns vintages of a dataflow, with oldest first and current flow last, and explains the meaning of 'vintage' in a way that disambiguates the resource. However, it does not explicitly differentiate this tool from sibling tools such as compare_vintages or describe_flow, so it stops short of the highest score.

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

  Usage Guidelines2/5

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

  No explicit guidance is given about when to use this tool versus alternatives. The description implies that it is relevant when you need historical published datasets, but it never mentions compare_vintages or other sibling tools, nor does it state any conditions for choosing this tool.

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

• search_codesB
  3.3/5.0
  Behavior3/5

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

  With no annotations, the description carries the full burden of behavioral disclosure. It usefully indicates a read-like search behavior and dimension-specific codelist mapping, but it does not explain what 'valid codes' means, how query matching works, or what the response contains. This is partial disclosure, not a complete behavioral contract.

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

  Conciseness4/5

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

  The description is two sentences with no filler; the primary action is front-loaded and the concrete use case follows immediately. It is appropriately concise, though slightly vague wording like 'valid codes' prevents a perfect score.

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

  Completeness2/5

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

  Given five parameters, zero schema descriptions, no output schema, and no annotations, the description is not sufficient for confident invocation. Notably, the required 'flow' parameter is unexplained, and the description provides no return contract or guidance about pagination/search behavior.

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

  Parameters2/5

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

  Schema description coverage is 0%, so the description must compensate. It clarifies the roles of provider, dimension, and query ('country name') through the geo-codelist example, but it completely omits 'flow' and 'limit.' Since 'flow' is required and remains opaque in both the schema and description, parameter understanding is incomplete.

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

  Purpose4/5

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

  The description clearly states the tool's function: finding valid codes for a single dimension, with a concrete example of mapping a country name to a provider's geo codelist. It is specific enough to distinguish it from data-fetching or entity-lookup tools, though it does not explicitly name or contrast siblings.

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

  Usage Guidelines4/5

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

  The phrase 'Use this to map a country name onto a provider's geo codelist' gives a clear, concrete context for when the tool should be used. However, it does not mention exclusions or alternatives, such as when to prefer find_entity or get_entity instead.

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

• list_providersA
  3.7/5.0
  Behavior3/5

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

  No annotations are present, so the description must carry the behavioral burden. It provides some useful context by mentioning 'known per-provider quirks,' which suggests the output includes caveats. However, it doesn't describe the output format, whether the operation is read-only, or any other behavioral details.

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

  Conciseness5/5

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

  The description is a single concise phrase, front-loaded with the core action and resource. No words are wasted, and the mention of per-provider quirks adds meaningful context without bloating the text.

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

  Completeness4/5

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

  For a zero-parameter listing tool, the description covers the essential purpose and grouping. It lacks explicit return-value details, but the absence of an output schema makes some ambiguity acceptable. Still, it could be more explicit about what the returned provider list contains.

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

  Parameters4/5

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

  The tool has zero parameters, so the baseline is 4. The description doesn't need to add parameter-level detail since there are none to document.

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

  Purpose4/5

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

  The description states a specific verb and resource: listing statistical providers, with a region-based organization. It is clear and understandable, though it doesn't explicitly differentiate from sibling tools like list_vintages, so it stops short of a 5.

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

  Usage Guidelines3/5

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

  The description implies the tool is for retrieving providers by region, but it doesn't explicitly state when to use it, when not to use it, or how it relates to alternatives. The usage context is inferable but not directly stated.

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

• fx_spotA
  4.6/5.0
  Behavior5/5

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

  With no annotations, the description carries full behavioral burden and does so exceptionally: it discloses the 14:15 CET fixing time, TARGET business days, closed-day fallback behavior, and the fact that non-EUR pairs are derived crosses marked with 'derived': true. It even instructs the agent to report that flag.

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

  Conciseness5/5

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

  The description is compact and front-loaded: the core rate semantics appear first, followed by essential caveats and a direct instruction. Every sentence earns its place, with no filler or repetition of schema fields.

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

  Completeness4/5

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

  Given there is no output schema and no annotations, the description covers the essential operational context: source, timing, holiday behavior, cross derivation, and a response field. It does not describe the full response shape or date format, but it is sufficient for correct invocation in most cases.

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

  Parameters4/5

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

  Schema description coverage is 0%, so the description must compensate. It clearly explains the base/quote relationship and that omitting date gives the latest rate. However, it does not specify the expected date format or further constrain the date parameter beyond the schema's default empty string.

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

  Purpose5/5

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

  The description precisely defines the tool's purpose: it provides the ECB euro reference rate and states the rate semantics as 'how many quote buy one base.' It also distinguishes itself by clarifying this is a daily fixing, not a traded spot rate, which separates it from the sibling fx_period_rate and generic spot tools.

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

  Usage Guidelines4/5

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

  The description gives clear context: omit date for latest, and closed days return the last publication before them. It does not explicitly name alternatives or state when not to use this tool versus fx_period_rate, but the fixing-vs-traded-rate distinction implies the appropriate use context.

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

• fetch_dataA
  4.7/5.0
  Behavior5/5

  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 and does so thoroughly. It explains return structure ('key', 'series', 'names', 'units', 'range'), missing data handling ('empty'), truncation semantics ('total' vs 'truncated'), and empty-response behavior. This far exceeds what would be expected for a data-fetch operation.

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

  Conciseness5/5

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

  The description is dense but every sentence earns its place. It opens with 'Fetch observations,' then systematically walks through request semantics, response structure, edge cases, and debugging guidance. No filler or repetition of trivial details.

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

  Completeness5/5

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

  Given the absence of an output schema, the description remarkably explains the full response shape, including 'key', 'series', 'names', 'units', 'range', 'empty', 'total', and 'truncated'. It also documents the empty-response behavior and a debugging technique. For a complex data tool with nested objects and no output schema, this is exceptionally complete.

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

  Parameters4/5

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

  The description compensates for 0% schema coverage by thoroughly explaining the 'key' parameter: how codes map to dimensions, how '+' joins codes, and how omitting a dimension matches all codes. 'start' and 'end' are also mentioned in the context of reading truncated histories. 'provider', 'flow', and 'limit' remain implied by their names, but the most complex parameter is well-covered.

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

  Purpose5/5

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

  States a specific verb and resource: 'Fetch observations.' The description goes beyond the generic name by explaining what the returned observations contain and how they are organized, making it clearly distinct from sibling tools like search_codes, list_providers, or describe_flow. The detail about series, keys, and codes leaves no ambiguity about this tool's role.

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

  Usage Guidelines4/5

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

  Provides clear context for when to use this tool, including how to ask which countries a flow covers by 'fetching with only FREQ pinned' and how to read labels 'without asking search_codes again.' It does not explicitly name all alternatives or state when not to use it, but the usage patterns and hints about narrowing start/end are strong contextual guidance.

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