Server Quality Checklist

Tool Scores

• initial_configB
  3.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 full transparency burden. It does disclose that the operation is a read and that credentials are not exposed, which is a useful safety trait. However, it omits details such as return format, error behavior, or whether any session/context is required, leaving some ambiguity about side effects and limitations.

  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, front-loaded sentence that directly states the tool's function and a key safety property. Every word earns its place, with no redundancy or fluff.

  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?

  Given the tool's simplicity (no params, no output schema), the description covers the core function but not the broader context. It lacks usage guidance, differentiation from 'portal_info', and any indication of what the configuration contains or how it might be used. This is sufficient for a trivial read but leaves room for improvement.

  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, so the schema is trivially complete. The description does not need to add parameter details. The baseline for zero-parameter tools is 4, and the description provides no conflicting information.

  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 'Read the public/portal configuration', which identifies a specific verb and resource. The addition of 'without exposing credentials' adds a safety constraint. However, it does not explicitly differentiate from the sibling tool 'portal_info', which may perform a similar read operation, so it lacks sibling differentiation.

  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. The description does not mention any prerequisites, exclusions, or alternative tools. An agent is left to guess when this tool is appropriate, especially given the overlapping 'portal_info' sibling.

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

• session_statusA
  3.8/5.0
  Behavior2/5

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

  No annotations are provided, so the description carries full responsibility for behavioral disclosure. It only says 'appears authenticated' without clarifying whether the tool makes a network request, has side effects, or what actions it takes if the session is not authenticated. This is insufficient for a tool that may interact with a live browser session.

  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 sentence that is entirely on topic. It is concise, front-loaded, and contains no verbose or redundant phrasing.

  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 (no parameters) and the presence of an output schema, the description covers the essential purpose. However, it does not provide usage context (e.g., preconditions or relationship to start_login), which is a minor gap for a session-status check.

  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, so the input schema is empty. With no parameters to explain, the baseline score is 4, and the description does not need to add parameter-level detail. No gap exists here.

  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: to report whether the persistent browser session appears authenticated. The verb 'Report' and specific outcome 'appears authenticated' distinguish it from siblings like start_login or portal_info, making its role 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 usage in scenarios where checking authentication status is needed (e.g., before deciding to log in), but it does not explicitly state when to use this tool versus alternatives like start_login or portal_info. No 'when not to use' guidance is provided.

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

• start_loginA
  3.8/5.0
  Behavior2/5

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

  With no annotations, the description must carry the full burden of behavioral disclosure. It mentions the profile is 'persistent,' implying statefulness, but does not explain critical behaviors: whether it blocks on user interaction, what side effects occur (e.g., creating a profile, storing cookies), or what the call returns. This leaves significant behavioral uncertainty.

  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, well-structured sentence that front-loads the verb and purpose. It contains no redundant or filler words, making it highly efficient.

  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?

  While the description clearly states the action, it omits crucial context such as the return value (despite an output schema existing), whether the call requires user interaction or waits, and how it fits into the broader login workflow with sibling tools. For a stateful, manual login process, this leaves too much unspecified.

  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, so schema coverage is trivially 100%. The description does not need to explain parameters, and the baseline for 0 params is 4. It adds no param-specific detail, but none is necessary.

  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 is specific and action-oriented: 'Open a persistent Chromium profile' clearly states the action, and 'for a manual Agora Plus login' specifies the purpose. This differentiates it from sibling tools like portal_info or session_status, which likely inspect or query rather than initiate a login.

  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 a clear context for use: it is for performing a manual Agora Plus login. However, it does not explicitly state when to use this tool versus alternatives (e.g., checking session_status first) or mention any prerequisites or exclusions.

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

• peri_inscriptionsA
  3.9/5.0
  Behavior4/5

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

  With no annotations, the description discloses that no reservation or cancellation is made, confirming read-only behavior. It also warns that the payload format is portal-version dependent and must be captured from an authenticated session, adding important behavioral 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?

  Three sentences, front-loaded with the purpose, each sentence adds distinct information: purpose, non-mutation, payload dependency. No wasted words.

  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?

  Given the lack of output schema and annotations, the description covers the read-only nature and payload requirement but omits details about response format or potential error conditions. It is adequate for a simple read tool but not fully comprehensive.

  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 single 'payload' parameter has no schema descriptions (0% coverage). The description adds that the payload format is portal-version dependent and must be captured from an authenticated session, providing some origin and dependency context, but it does not specify internal structure or required fields.

  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 'Read current peri-school inscriptions through the authenticated browser session,' using a specific verb (Read) and resource (peri-school inscriptions). It distinguishes from siblings by emphasizing read-only and the authenticated session context.

  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 usage requires an authenticated session ('through the authenticated browser session') but does not explicitly compare to alternatives or state when not to use. No exclusions are mentioned, so guidance is only implied rather than explicit.

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

• portal_infoA
  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 for behavioral disclosure. It states that the tool returns 'non-sensitive' data and is 'read-only,' which conveys safety and side-effect-free behavior. However, it does not disclose authentication requirements, error behavior, or what happens on failure. For a simple tool, this is adequate but not comprehensive.

  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, front-loaded sentence that directly states the action and scope. Every word earns its place, with no unnecessary filler. It is appropriately sized for a zero-parameter tool.

  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 has no parameters, an output schema is present, and the description states the purpose and the read-only nature, the description is largely complete. It could mention more about the 'supported read-only scope' or when to use it relative to siblings, but for a simple metadata tool, it 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?

  The tool has zero parameters, so schema coverage is trivially 100%. The rubric assigns a baseline of 4 for zero parameters. The description adds no parameter information, but none is needed.

  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 'Return non-sensitive portal metadata and the supported read-only scope.' This identifies a specific verb (Return), resource (portal metadata), and scope (read-only), which distinguishes it from sibling tools like initial_config, start_login, and session_status. The qualifier 'non-sensitive' adds precision.

  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 usage: when you need portal metadata and supported read-only scope, this is the tool. However, it does not explicitly state when to use it over alternatives or mention any exclusions. Sibling tools exist, but no differentiation guidance is provided.

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