Server Quality Checklist

Tool Scores

• resolve_figiA
  4/5.0
  Behavior4/5

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

  With no annotations provided, the description carries the full burden. It discloses that the tool queries OpenFIGI, performs a pure string mapping, and verifies against SEC data, providing useful process context. It does not detail error handling or failure modes, but these are less critical for a lookup tool.

  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 sentences long, front-loaded with the primary purpose, and each sentence adds meaningful process detail without redundancy. It is concise and well-structured.

  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?

  The description adequately covers the main process steps and external dependencies. Since an output schema exists, return values are likely documented there. Minor gaps include not mentioning what happens if the FIGI is not found or the mapping fails, but overall it is complete enough for most use cases.

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

  Parameters3/5

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

  The input schema already provides a complete description of the 'figi' parameter, including an example. The description adds no additional semantic meaning or constraints beyond what the schema already states, so the baseline of 3 is appropriate.

  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 clearly states the verb 'Resolve' and the resource 'Bloomberg FIGI' to a 'Yahoo-convention ticker symbol'. It distinguishes itself from sibling tools like resolve_cusip and resolve_ticker by specifying the exact input and output format.

  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 usage context is implied by the description: if you have a FIGI and need a Yahoo ticker, you would use this tool. However, there is no explicit guidance on when to use this over alternatives or any when-not-to-use conditions.

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

• lookup_cikA
  4.1/5.0
  Behavior4/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. It discloses the data source (SEC's company_tickers.json), coverage (10,000+ US tickers), cache freshness (24-hour window), and the metadata returned (entity name, SIC code, tickers, exchanges, fiscal year end, addresses). This is strong context, though it doesn't explicitly state the operation is read-only.

  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 six sentences, front-loaded with the core purpose. Each sentence adds value—explaining the CIK, the workflow, metadata, data source, and caching—though it could be slightly tightened without losing meaning.

  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?

  Despite having no annotations and only one parameter, the description covers the tool's purpose, role in the pipeline, data source, freshness, and returned metadata. With an output schema present, it doesn't need to describe return values. Minor gaps like error handling or invalid ticker behavior are acceptable for this simple lookup tool.

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

  Parameters3/5

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

  Schema coverage is 100% with a clear description for the 'ticker' parameter ('Stock or ETF ticker symbol'). The description adds context about US ticker coverage but does not meaningfully enrich the parameter beyond what the schema already provides, so the baseline score of 3 is appropriate.

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

  Purpose5/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 with a specific verb and resource: 'Look up a ticker's SEC Central Index Key (CIK) and entity metadata.' It distinguishes itself from sibling resolvers by focusing on SEC CIK and explicitly positions itself as a prerequisite step for get_etf_holdings.

  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 explicitly says 'This is the first step before calling get_etf_holdings,' providing clear when-to-use context. However, it does not mention when not to use the tool or compare it directly with sibling tools like resolve_ticker, resolve_cusip, or resolve_figi.

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

• resolve_cusipA
  4.2/5.0
  Behavior4/5

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

  With no annotations, the description carries full burden. It transparently discloses the OpenFIGI batched query, suffix mapping, SEC verification, and veto on gross name mismatch. The note that CUSIP is input-only and outputs carry different identifiers is valuable. It stops short of 5 by not describing failure modes or error behavior, but it is unusually rich.

  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, front-loaded with the core purpose, followed by concise process details and a critical input/output note. Every sentence earns its place with no fluff or repetition.

  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 the multi-step resolution process (OpenFIGI query, mapping, verification), the description covers the key behaviors and constraints. An output schema exists, so return-value details are not needed. Minor gaps like failure handling or rate limits keep it from a 5, but it is highly complete for a complex tool.

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

  Parameters3/5

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

  The input schema covers 100% of parameter documentation with a clear description ('9-character CUSIP (or 7-character SEDOL) identifier'). The tool description adds no additional parameter-level meaning beyond what the schema provides, so the baseline 3 is appropriate.

  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 opens with a clear, specific verb+resource+outcome: 'Resolve a CUSIP (or SEDOL) identifier to a Yahoo-convention ticker symbol.' This precisely states what the tool does and naturally distinguishes it from siblings like resolve_figi or lookup_cik by input type and output.

  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?

  Usage is strongly implied through the purpose statement and process details (e.g., handling both CUSIP and SEDOL, mapping to Yahoo ticker). However, it does not explicitly name alternatives or state when not to use it, so it falls short of a 5. The sibling tool names provide additional context but are not referenced.

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

• resolve_tickerA
  4.2/5.0
  Behavior4/5

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

  No annotations are present, so the description carries the burden. It discloses important behaviors: the transformation is a 'pure string transformation (no Yahoo network calls)' and that it 'verifies against SEC company_tickers.json and/or OpenFIGI'. This adds meaningful context beyond the schema.

  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 sentences, zero waste, with the core purpose front-loaded. The second sentence provides valuable technical context without unnecessary elaboration.

  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 two-parameter tool with an output schema and no annotations, the description covers the core process, clarifies network usage, and mentions external verification sources. It lacks some edge-case behavior details but is reasonably complete.

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

  Parameters3/5

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

  Schema coverage is 100%, so the schema documents both parameters adequately. The description hints at 'exchange suffix mapping' but does not add significant detail beyond what the schema already provides, matching the baseline for full schema coverage.

  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 ('Resolve') and resource ('raw ticker symbol to its Yahoo-convention equivalent'), clearly identifying the tool's unique function. This distinguishes it from sibling tools that resolve other identifiers (CIK, CUSIP, FIGI).

  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 context is clear: use when a raw ticker needs conversion to Yahoo format. However, it does not explicitly contrast with sibling tools or provide exclusions, so it stops short of a full 5.

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

• get_etf_holdingsA
  4.3/5.0
  Behavior4/5

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

  With no annotations provided, the description takes on full disclosure responsibility. It specifies the data source (monthly N-PORT filings), the exact fields returned, and deliberately notes that CUSIPs are excluded. This adds meaningful behavioral context beyond the schema, though it does not mention potential limitations like filing delays.

  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 concise paragraphs, front-loaded with the core action in the first sentence, followed by essential context and output details. Every sentence provides value; there is no redundancy or filler.

  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?

  Despite moderate complexity, the description covers the tool's purpose, data source, returned fields, and an explicit exclusion (no CUSIPs). With an output schema present, detailed return structure is unnecessary, making this description complete for an AI agent.

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

  Parameters3/5

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

  Schema description coverage is 100%, with both parameters well-documented: ticker has examples and cik explains its optional role and the lookup-cik shortcut. The description itself adds no further parameter-level semantics, so the baseline score of 3 is appropriate.

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

  Purpose5/5

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

  The description opens with 'Get the complete holdings of any US-registered ETF via SEC EDGAR,' clearly stating the tool's specific action, resource, and scope. It distinguishes itself from sibling tools (lookup_cik, resolve_ticker, etc.) which are identifier-resolution utilities rather than data-retrieval 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 provides clear context about when the tool applies (any US-registered ETF, using Form N-PORT filings) but does not explicitly state when-not-to-use or compare with alternatives. It references lookup_cik only in the schema, not the description, so the guidance is contextually clear but lacks explicit exclusions.

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