Server Quality Checklist

Tool Scores

• simulate_reductionA
  4/5.0
  Behavior3/5

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

  No annotations provided, so description carries full burden. It describes a simulation ('what-if', 'projected'), implying read-only behavior, but does not explicitly state that it has no side effects or requires specific permissions.

  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?

  Description is concise and well-structured: one-line summary, then Args, then Returns. Every sentence adds value with no redundancy.

  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?

  Output schema exists, so description need not detail return values but still lists key return fields (baseline, applied initiatives, reductions, capex). For a simulation tool with two parameters and clear return, this is sufficient.

  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 coverage is 0%, but description adds meaning: clarifies 'portco' as slug or name, and 'initiative_ids' as a list from list_initiatives. This compensates well, though could include more detail on valid values or constraints.

  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?

  Description clearly states it performs 'What-if analysis' by applying a subset of initiatives and returning projected post-lever emissions. It effectively distinguishes from sibling tools like gap_to_target (gap calculation), get_portco_emissions (baseline), list_initiatives (list initiatives), and list_portcos (list portcos).

  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?

  Description implies usage for hypothetical scenarios but lacks explicit guidance on when to use versus alternatives (e.g., when not to use or mention of prerequisites). Context from sibling tools helps but not explicitly stated.

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

• list_initiativesA
  4.2/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 disclosing behavior. It explains the filtering options and return structure, which is sufficient for a read-only list tool. However, it does not mention any potential side effects, authorization requirements, rate limits, or error handling. A higher score would require more detailed behavioral context, such as pagination or data freshness.

  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, with the main purpose stated in the first sentence. The Args and Returns sections are clearly formatted and front-loaded. Every line serves a purpose with no redundancy or fluff. It is well-structured and easy to parse quickly.

  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 that the tool has an output schema (though not provided in the input), the description adequately documents the return format with field names and descriptions. The two optional parameters are fully explained. For a straightforward list tool, the description covers all essential information (purpose, parameters, returns, use cases). It only lacks advanced context like pagination or sorting, which would be nice but not necessary.

  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 input schema has zero description coverage, but the description's Args section explicitly explains each parameter's purpose and values. For status, it enumerates the valid options ('planned', 'in_progress', 'complete'), which adds semantic value beyond the schema's bare type definitions. The description also clarifies that omitting portco returns all portfolio initiatives, providing default behavior context.

  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 begins with 'List decarbonization initiatives with estimated reduction, capex, and payback,' which is a specific verb-resource combination. It clearly distinguishes this tool from its siblings: list_portcos lists companies, gap_to_target and simulate_reduction are analytical, and get_portco_emissions retrieves emission data. The purpose is unambiguous and well-scoped.

  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 states 'Useful for cost-curve analysis, payback screening, and status roll-ups,' which provides clear context on when to use the tool. However, it does not explicitly exclude scenarios where alternatives might be better, nor does it mention prerequisites or when not to use it. The sibling tools are not directly compared, but the use cases are well defined.

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

• gap_to_targetA
  4.3/5.0
  Behavior4/5

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

  No annotations exist, so the description fully carries behavioral transparency. It clearly describes the computation, inputs, and return structure, indicating a read-only behavior. However, it does not mention dependencies like forecast data availability.

  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 efficient, using three sentences plus an args/returns block. It is front-loaded with the purpose. Could be slightly more structured but remains clear and without redundancy.

  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 tool's simplicity (2 parameters, simple computation), the description covers all necessary aspects: purpose, inputs, and return values. The presence of an output schema complements the description, making it highly complete.

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

  Parameters5/5

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

  With 0% schema description coverage, the description adds significant meaning: it explains that 'portco' is a slug or name and 'target_year' defaults to 2030, plus lists all return fields. This fully compensates for the schema's lack of descriptions.

  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 states the tool computes the gap between the current trajectory and an SBTi-aligned target, specifying the method and inputs. This distinguishes it from siblings like get_portco_emissions or simulate_reduction.

  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 explains how the gap is computed but does not explicitly guide when to use this tool over alternatives. Usage context is implied but no exclusion criteria 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.

• list_portcosA
  4.5/5.0
  Behavior4/5

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

  No annotations provided, but description covers that it lists all companies and specifies return fields. No hidden behaviors; adequate for a simple read-only list.

  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, front-loaded with purpose and immediate value, no wasted words.

  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 0 parameters and output schema exists, description still enumerates return fields for clarity. Provides complete starting point for portfolio queries.

  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?

  Input schema is empty (0 parameters). Description adds no parameter info because none needed. Baseline 4 for 0-param tools.

  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?

  Description explicitly states 'List all 10 Northwood portfolio companies' with specific fields (sector, status, headline metrics), clearly distinguishing from sibling tools like gap_to_target or get_portco_emissions.

  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?

  Explicitly says 'Use this as the starting point for portfolio-level questions', indicating when to use. No explicit when-not or alternatives, but context is clear enough.

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

• get_portco_emissionsA
  4.6/5.0
  Behavior5/5

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

  Despite no annotations, the description fully discloses input behavior (slugs vs name substrings, optional year/scope filtering) and output shape (dict with emissions map in tCO2e). It implies read-only access, which is appropriate for a 'get' tool.

  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 well-structured with Args and Returns sections, providing clear information without excessive verbosity. It could be slightly more terse, but the structure aids readability.

  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 get tool with an output schema, the description covers all parameters and return format. It does not mention error handling or authentication, but these are not critical for completeness given the tool's straightforward nature.

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

  Parameters5/5

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

  Given 0% schema description coverage, the description adds crucial meaning: portco can be a slug or name substring, year restricts to a single year, and scope filters to 1 or 2. This far exceeds what the schema (just titles and types) provides.

  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 gets Scope 1 and 2 emissions for a portfolio company, with a specific verb and resource. It distinguishes itself from sibling tools like list_portcos or simulate_reduction, which serve different purposes.

  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 explains the tool's purpose and parameter options, but does not explicitly state when to use it over siblings. However, the narrow scope makes usage clear without needing exclusion clauses.

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