Server Quality Checklist

Tool Scores

• godel_most_activeC
  2.4/5.0
  Behavior2/5

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

  With no annotations present, the description carries the full burden of disclosing behavior, but it only states a noun phrase. It does not mention whether the data is real-time or delayed, whether it is sorted by volume/percentage, or whether the result is a list. Key behavioral aspects such as pagination or data freshness are omitted.

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

  Conciseness2/5

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

  The description is a single short phrase, but it is under-specification rather than concise completeness. It provides no actionable information beyond what the title and name already imply. A concise, useful description should include the action and key context (e.g., list, sorted, live).

  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?

  For a tool with 2 optional parameters, no output schema, no annotations, and several siblings, the description is inadequate. It fails to explain what the tool returns, how the 'tab' parameter affects results, or how this differs from quote/search tools. The description leaves the agent without enough context to select and invoke the tool correctly.

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

  Parameters3/5

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

  Schema description coverage is 100% (both parameters have descriptions), so the baseline is 3. The tool description adds no additional meaning about parameters. The parameter descriptions themselves are minimal—'Leaderboard' for tab and 'How many rows' for rows—but the enum values (ACTIVE, GAINERS, LOSERS) are somewhat self-explanatory. The description does not clarify what each tab value returns or how 'most active' is defined.

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

  Purpose3/5

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

  The description 'Most active securities across the market' identifies the resource (securities) and scope (market), but lacks an explicit verb like 'list' or 'retrieve' to clarify the action. It is vague about whether this returns a list, a snapshot, or a specific security, and does not differentiate from siblings like godel_quote or godel_live_quote.

  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 usage guidance is provided. The description does not state when to use this tool versus alternatives (e.g., godel_quote for individual securities, godel_search for finding securities). There are no prerequisites, exclusions, or alternative tool mentions.

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

• godel_newsC
  2.9/5.0
  Behavior2/5

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

  With no annotations, the description carries full responsibility for behavioral disclosure. It only states 'recent' and 'optionally filtered to a ticker' but does not explain sorting, pagination, output format, data scope, or any access requirements. This is insufficient for an agent to understand side effects or limitations 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.

  Conciseness4/5

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

  The description is a single, clear sentence with no redundant content. It front-loads the core purpose. However, it is extremely brief and could benefit from a structured mention of key parameters or usage context, so it does not earn a 5.

  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 and no annotations, the description should explain what data is returned and any important behavior. It does not mention the shape of the response, recency bounds, or how news and filings are combined. The tool is simple but still under-specified for an agent to use confidently.

  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 baseline is 3. The description reiterates the ticker filter but adds no new meaning for the limit parameter or additional details about how filtering behaves. It does not compensate for the 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 clearly indicates the tool returns recent news and filings, with an optional ticker filter. It is specific about the resource (news/filings) and distinguishes itself from sibling tools by its unique subject matter, though it lacks an explicit verb like 'list' or 'get'.

  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. The description does not mention any exclusions, prerequisites, or contrast with sibling tools like godel_quote or godel_financials. Usage is only weakly implied by the tool's name and context.

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

• godel_searchC
  2.9/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 full responsibility for behavioral disclosure. It does not mention that the tool is a read-only search, what result format to expect, or any limitations such as pagination. It only provides a generic search statement, which is insufficient for full transparency.

  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, clear sentence with no redundant words or filler. It efficiently conveys the tool's core purpose, earning top marks for 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 no output schema and no annotations, the description should provide more context about return values and usage behavior. It fails to explain the response structure or any edge cases, making it incomplete for a simple search tool despite the clear purpose.

  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 schema already covers both parameters with descriptive text (query and types), achieving 100% coverage. The description adds no new parameter-related meaning beyond echoing the result types already listed in the default value for types, 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.

  Purpose4/5

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

  The description uses the specific verb 'Search' and clearly identifies the resource as 'instruments, legal entities, and news,' establishing a broad search scope. It distinguishes from siblings by covering multiple entity types, though it does not explicitly contrast with godel_news for news-specific searches.

  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 like godel_news or godel_quote. The description simply states what the tool does without providing situational context or exclusions, leaving the agent to infer usage.

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

• godel_ratingsB
  3.1/5.0
  Behavior2/5

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

  With no annotations provided, the description carries the full transparency burden. It discloses the data type (ratings and price targets) but does not explain the meaning of 'recent,' the range of rating actions (e.g., upgrades/downgrades), or any limitations. The tool's read-only nature is implied but not explicitly stated.

  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 sentence that directly conveys the tool's purpose. Every word contributes meaning, with no redundancy or filler. It is appropriately sized for the tool's simplicity.

  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 one-parameter tool with no output schema and no annotations, the description is adequate but minimal. It states the core functionality but omits useful context like the time period of 'recent' or the nature of 'rating actions.' Given the tool's simplicity, this is a marginal score; more detail would improve completeness.

  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% as the only parameter 'ticker' is described. The description adds no additional parameter information, but given the high coverage, the baseline of 3 is appropriate. No extra semantics are needed for a single well-documented parameter.

  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 provides 'Recent analyst rating actions and price targets for a ticker,' which is specific and distinguishes it from siblings like godel_quote (current price) and godel_financials (fundamentals). It lacks an explicit verb like 'retrieve' or 'get,' but the noun-phrase description is unambiguous.

  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 this tool versus alternatives. It does not mention exclusions, preferred contexts, or comparisons to sibling tools. The description only states what the tool returns, leaving the agent to infer usage.

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

• godel_quoteB
  3.4/5.0
  Behavior2/5

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

  No annotations are provided, so the description bears the full burden of disclosing behavior. It does reveal that the quote is delayed and lists return fields, which is useful. However, it does not explicitly state it is a read-only/safe operation, nor does it mention absence of side effects, authentication, or latency characteristics. Given the lack of annotations, this is insufficient.

  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, focused sentence: 'Delayed last-close snapshot for a ticker (last, volume, dollar volume).' Every word contributes value, with no filler or redundancy. It is front-loaded with the key qualifier 'Delayed' and immediately specifies the output 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?

  For a simple quote tool with one parameter and no output schema, the description is quite complete. It names the output fields (last, volume, dollar volume) and the delayed nature. It does not describe the exact response JSON structure or error behavior, but given the low complexity and the presence of sibling tools, this is sufficient. It could benefit from stating that it returns a snapshot for a given ticker, which is already clear.

  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 schema provides a description for the single parameter 'ticker' with an example (TSLA), covering 100% of parameter semantics. The tool description adds no additional meaning 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.

  Purpose4/5

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

  The description clearly states the tool returns a 'Delayed last-close snapshot' with specific fields (last, volume, dollar volume). The word 'Delayed' differentiates it from sibling godel_live_quote, making the scope clear. Though it lacks an explicit verb like 'gets', the resource and scope are unambiguous.

  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 when to use it via 'Delayed' versus the sibling 'godel_live_quote', but it does not explicitly state 'use for last-close data' or 'use godel_live_quote for real-time quotes'. There is no direct when/when-not guidance, only an implied context.

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

• godel_historicalA
  3.6/5.0
  Behavior2/5

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

  No annotations are present, and the description does not disclose any behavioral details beyond the output type. It does not mention whether it is a read-only operation, how data is ordered, limits on historical depth, or error handling, leaving the agent with minimal transparency.

  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 that efficiently conveys the core purpose without redundancy. It is appropriately concise, though slightly terse.

  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 historical data retrieval tool, the description and schema are minimally adequate. However, the lack of an output schema and absence of information about return format, time ranges, or edge cases make it only partially complete for an agent to fully anticipate behavior.

  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 descriptions cover all three parameters (bars, ticker, resolution) with defaults and examples, achieving 100% coverage. The description adds no additional meaning beyond the schema, so it meets the baseline but does not enhance parameter understanding.

  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 provides historical OHLCV bars for a ticker at a resolution. The resource (historical prices) and granularity (bars) are specific, and it is easily distinguished from sibling tools that provide current quotes or live quotes.

  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 of 'historical' implies it should be used when past price data is needed, distinguishing it from quote/live_quote tools. However, it does not explicitly state when not to use it or name alternatives, so it falls short of full explicit guidance.

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

• godel_describeA
  3.8/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 does provide transparency by listing the output fields, but it does not mention any side effects, error behavior, whether data is real-time or delayed, or the possibility of null fields. The description adds some value beyond the schema but lacks deeper 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.

  Conciseness5/5

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

  The description is a single, concise sentence that front-loads the core purpose and lists the returned fields without unnecessary words. Every part of the description earns its place.

  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 tool's simplicity (one parameter, no output schema, no annotations), the description is largely complete: it states the purpose and lists the return fields. However, it could be slightly more complete by explicitly stating that it is a read-only operation or what happens if the ticker is invalid, but this is minor given the low complexity.

  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 only parameter (ticker) is fully covered by the schema with a clear description ('Ticker symbol, e.g. AAPL'). The tool description adds no extra meaning beyond the schema, 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 purpose: 'Overview for a ticker' and lists the exact fields returned (name, exchange, instrument type, last close, CIK/LEI). This distinguishes it from sibling tools like godel_quote (likely real-time price) and godel_financials (financial statements), making the tool's scope unmistakable.

  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?

  Usage guidance is implied rather than explicit. The description tells the agent this is a general overview tool, so an agent can infer it should be used when basic security info is needed. However, no alternatives are mentioned (e.g., 'use godel_quote for real-time prices'), so the agent must rely on sibling names to differentiate.

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

• godel_financialsA
  3.8/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. It discloses that the data is standardized and annual, and lists the included metrics, which is useful. However, it does not describe the return shape (e.g., array vs object), whether valuation multiples are per-period or trailing, or any limitations such as data coverage. It is not misleading but lacks depth.

  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?

  Single concise sentence, front-loaded with the core purpose ('Standardized annual financials'), and includes useful examples of contents. No wasteful wording or redundant schema 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 no output schema, the description does a decent job of indicating the return content (revenue, margins, income, cash flows, valuation multiples). However, it omits structural details like whether results are grouped by year, which the periods parameter implies. It is mostly complete for a simple data retrieval 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 both parameters described ('Ticker symbol' and 'How many fiscal years'). The description adds context by mentioning the financial categories, which implies what the data represents, but it does not add significant meaning beyond the schema. The 'periods' parameter is well-defined in the schema.

  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 provides 'Standardized annual financials' with specific content categories (revenue, margins, income, cash flows) plus valuation multiples. This specific verb-resource combination distinguishes it from sibling tools like godel_quote (prices) and godel_historical (price history).

  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 gives clear context (annual financials for a ticker) but does not explicitly state when to prefer this tool over alternatives like godel_ratings or godel_quote. No exclusions or alternative tool mentions are provided, leaving the comparison to the agent to infer from sibling names.

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

• godel_live_quoteA
  4/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 the live-access requirement but does not describe the response format, potential delays, error conditions, or rate limits. It provides some value beyond the name but lacks depth for a no-annotation 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 extremely concise: two short sentences, front-loaded with the core purpose, and no wasted words. It is well-structured and immediately informative.

  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 single-parameter tool with no output schema, the description covers the essential purpose and a key prerequisite. It is complete enough for selection and basic invocation, though it does not specify the return value format; still, 'quote' implies content, making this acceptable.

  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 schema already fully covers the 'ticker' parameter with a clear example ('AAPL') at 100% coverage. The description adds no additional parameter explanation, 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 provides a 'Real-time quote for a ticker', which is a specific verb+resource scope. It differentiates from sibling godel_quote by emphasizing 'real-time', making its unique function evident.

  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: use for real-time quotes, and it notes the prerequisite 'Requires a provider with live access'. However, it does not explicitly name alternatives or mention when not to use, falling short of a 5.

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