Server Quality Checklist

Tool Scores

• librus_getB
  3.4/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 full burden of behavioral disclosure, and it does assert the key safety-relevant trait: the tool is read-only and non-destructive. However, it does not describe return values, pagination, or failure behavior, and since the schema has no output schema, the agent knows neither the shape of the result nor what to expect on unsupported cases.

  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?

  Two short sentences with the primary verb+resource front-loaded. The second sentence earns its place by constraining scope (read-only, no arbitrary URL), even though it partially restates the word 'read.' Overall it is tight and free of filler.

  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 description plus fully documented schema adequately cover what the tool does and how to call it, including the dependency expressed in the account_login parameter. Yet with no output schema and no description hint about return shape, an agent invoking this across 27 heterogeneous resources has an at-a-glance fixed description of the response.

  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%: the enum of 27 resources, the YYYY-MM-DD pattern with 'ignored for other resources', and the 'account_login returned by librus_profiles' dependency are all already documented in the input schema. The tool description adds no parameter-specific meaning, which fits the baseline of 3 for high schema coverage.

  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 a specific verb ('Read') and resource ('a supported Librus API resource'), so the core capability is clear. The added boundary — 'accepts no arbitrary URL or write operation' — separates it from any generic API-access tool, and the read-only framing naturally distinguishes it from the auth-oriented siblings (librus_profiles, librus_logout), though it never names them.

  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 conveys when to use the tool implicitly: when a supported Librus resource needs to be retrieved. It makes explicit exclusions (no arbitrary URLs, no writes), which helps an agent know what NOT to do here, but it does not name an alternative tool or state a precondition such as retrieving account_login via librus_profiles first.

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

• librus_logoutA
  4.2/5.0
  Behavior4/5

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

  No annotations are provided, so the description bears full responsibility for disclosing behavior. It clearly states the exact state that changes ('cookies and tokens') and adds persistence context with 'Nothing is persisted to disk.' This goes beyond a bare verb and gives an agent a solid understanding of the tool's boundary, even though it does not explicitly describe post-logout authentication state.

  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 short sentences with no filler, and the main action is front-loaded. The second sentence adds an important clarifier about disk persistence without 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?

  For a zero-parameter, no-annotation, no-output-schema tool, the description is largely complete: it says what is deleted, in what scope, and what is not deleted. An agent may need to infer that subsequent tool calls will require reauthentication, but that follow from the stated clearing of cookies and tokens and does not make the description inadequate.

  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 and 100% schema coverage, so there are no parameter semantics to clarify. The description correctly does not mention parameters, and the baseline of 4 for no-parameter tools applies.

  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 states a specific action ('Clear all in-memory Librus cookies and tokens') with a concrete resource. It clearly distinguishes the tool from siblings like librus_get and librus_profiles by targeting session/logout state rather than profiles or data retrieval. There is no ambiguity about what the tool is for.

  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 logging out or ending a session by clearing auth data, so an agent can infer when to use it. However, it does not explicitly say when to use this tool instead of siblings like librus_profiles or librus_get. It could have named these alternatives and given conditions, but the use case is reasonably clear from the token-based action.

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

• librus_profilesA
  4.2/5.0
  Behavior3/5

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

  The description conveys that this is a read-only listing operation and that it depends on the 'configured Librus Portal account,' which is useful. However, no annotations are provided, and the description does not elaborate on possible return formats, errors, or whether multiple accounts may be returned.

  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 sentences with no filler. The first states the primary purpose; the second gives an essential workflow tidbit. It is front-loaded and each sentence 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?

  For a no-parameter tool with no output schema, the description is largely complete: it specifies what the tool lists and how the return value should be used. It does not describe the return structure in detail, but that is a minor omission 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.

  Parameters4/5

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

  The tool has zero parameters and an empty input schema, so there are no parameter details to clarify. A baseline of 4 for a 0-parameter tool 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 states a clear action and resource: 'List Librus Synergia accounts linked to the configured Librus Portal account.' It also explicitly names the sibling librus_get as the consumer of the returned data, which distinguishes it from related 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 direct workflow guidance: 'Use the returned login with librus_get.' This tells an agent exactly what to do with the result, though it does not explicitly cover when not to use the tool or mention alternate scenarios.

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