Server Quality Checklist

Tool Scores

• solar_batteryA
  3.8/5.0
  Behavior3/5

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

  Description implies a read-only operation with 'Real-time data' and lists return fields, but does not explicitly state non-destructive nature, authentication needs, or rate limits. Annotations are absent, so description carries the burden.

  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 effectively convey purpose and return data without redundancy. No unnecessary words.

  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 annotations or output schema, the description sufficiently explains the tool's function and the data it returns. Lacks mention of potential limitations or prerequisites, but adequate for a simple read tool.

  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 no parameters and schema coverage is 100%, so no additional parameter info is needed. Description adds value with field details but is not required; baseline score of 4 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 it provides real-time data from the BYD Battery-Box Premium HV, distinguishing it from sibling tools like configure_inverter, solar_devices, solar_meter, and solar_power_flow.

  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 on when to use this tool versus alternatives, e.g., for specific battery metrics vs. overall system status. The description only lists data fields without context.

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

• solar_power_flowA
  3.9/5.0
  Behavior3/5

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

  No annotations are provided, so the description must convey behavioral traits. It implies a read-only operation but does not explicitly state it as non-destructive or idempotent. The return fields are detailed, but beyond that, no information on permissions, rate limits, or side effects is given.

  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 sentences, front-loaded with the primary purpose, and the second sentence lists all output fields efficiently. No redundant or extraneous information.

  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?

  For a read-only tool with no parameters and no output schema, the description fully covers what the tool returns, including units and sign conventions. It is complete enough for an agent to understand the tool's output without additional context.

  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?

  There are no parameters, and schema description coverage is 100% trivially. The baseline for zero parameters is 4, and the description appropriately focuses on the output rather than parameters, which is correct.

  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 it provides real-time power flow data from a specific inverter model, and lists all returned fields. The verb 'Returns' implies a read operation, and the resource is well-defined. It distinguishes itself from sibling tools like solar_battery or solar_meter by focusing on overall power flow.

  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 given on when to use this tool versus alternatives. It does not mention use cases, prerequisites, or when not to use it. The description is purely factual without contextual recommendations.

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

• solar_meterA
  4.4/5.0
  Behavior4/5

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

  No annotations provided, so description bears full burden. It explains real-time data, sign convention for power, and lists all measurements. Could mention read-only nature but not required. No contradictions.

  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, no redundant words. Every sentence provides essential information.

  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?

  No output schema, so description must cover return values. It lists all fields with brief explanations and sign convention. Lacks explicit units for voltage/current (though implied) and error handling, but adequate 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.

  Parameters4/5

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

  No parameters, so schema coverage is 100%. Description adds value by explaining field meanings and sign convention, which goes beyond the empty 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 it returns real-time data from a Fronius Smart Meter at the grid feed-in point, lists specific measurements, and distinguishes itself from sibling tools like solar_power_flow or solar_battery.

  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 implies usage for grid feed-in point data, and sibling tools cover other areas (configuration, battery, device list, power flow). However, no explicit 'when not to use' or alternatives are given.

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

• configure_inverterA
  4.7/5.0
  Behavior5/5

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

  With no annotations, the description carries full burden and delivers: it discloses saving to ~/.fronius-mcp.json with persistence, automatic scheme/port stripping, and return behavior (confirmation or connectivity warning).

  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?

  Description is concise (4 sentences plus Args/Returns) and well-structured with clear sections. Every sentence adds value; minor redundancy ('useful for first-time setup' is implicit) but overall efficient.

  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 (1 param, no nesting), the description covers purpose, usage, side effects, parameter details, and return behavior. Output schema exists and description explains return values adequately. Sibling tools are distinct.

  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?

  Schema provides only 'Host' string without description (0% coverage). The description compensates fully: specifies IP/hostname format, example, and behavior (scheme/port stripping).

  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 'Configure the Fronius inverter IP address or hostname.' It specifies the verb (configure) and resource (inverter IP/hostname), and distinguishes itself from sibling tools (solar_battery, solar_devices, etc.) which handle other aspects.

  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 says 'Call this once to tell the MCP server where your inverter lives' and notes persistence across restarts. It implies a one-time setup but could explicitly state when not to use or that it's a prerequisite for other tools. Still clear overall.

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

• solar_devicesA
  4.7/5.0
  Behavior5/5

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

  The description fully explains the return format (dict with device classes, list of devices with bus index and serial number) and the meaning of empty lists. Since no annotations are provided, the description carries the full transparency burden and does so completely.

  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 primary action, followed by detailed output format and a use case. Every sentence adds value 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 has no parameters and no output schema, the description is complete: it explains the purpose, output structure, and interpretation of results. It adequately covers the tool's functionality.

  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?

  There are no parameters (empty input schema), so the baseline is 4. The description does not need to add parameter info, and it correctly focuses on the output behavior.

  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 lists all devices connected to the Fronius inverter system, using specific verb 'lists' and resource 'devices'. It distinguishes from sibling tools like 'configure_inverter' or 'solar_battery' by covering all device classes.

  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 includes a use case ('useful for verifying system topology or diagnosing missing devices'), which implies when to use. It lacks explicit exclusions or direct comparisons to sibling tools.

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