Server Quality Checklist

Tool Scores

• statusA
  4.3/5.0
  Behavior3/5

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

  Annotations already declare readOnlyHint, idempotentHint, and openWorldHint, covering the safety profile. The description adds the specific status fields and a use-case tip, but does not disclose additional behavioral traits such as authentication requirements or rate limits. With annotations present, this is adequate but not rich.

  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 concise sentences, front-loaded with the purpose and followed by actionable usage advice. No unnecessary words or repetition.

  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 simple status-check tool with no parameters, the description is complete. It explicitly lists the return fields, compensating for the lack of an output schema, and provides a clear usage scenario.

  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 covers everything trivially. The description adds no parameter details, which is appropriate. Per the rubric, a 0-parameter tool gets a baseline of 4.

  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 function with a specific verb ('Check') and resource ('GlassyPic account status'), and enumerates the exact data returned (login state, tier, credits remaining, credit reset time). It distinguishes itself from sibling tools like login/logout/upgrade by being the read-only status checker.

  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 concrete usage context: 'Use this before batch processing to verify sufficient credits.' It does not explicitly mention when not to use or name alternatives, but the guidance is clear and practical for the intended workflow.

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

• loginA
  4.7/5.0
  Behavior5/5

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

  The description richly discloses behaviors beyond annotations: it opens a browser window, supports Google/Facebook/email, automatically picks up the account, and stores the access token and email locally at ~/.glassypic/session.json with file mode 0600 until logout. This is far more transparent than the minimal annotations (openWorldHint=true) and covers side effects, storage, and security posture.

  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 four sentences, each contributing essential information: the action, the browser flow, the credit benefit and related status tool, and the local session storage. It is front-loaded with the core purpose and avoids redundancy. Every sentence earns its place.

  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 no parameters, no output schema, and minimal annotations, the description is remarkably complete. It covers the login flow, credit implications, related tool usage, and security details about the stored session. It also clarifies that login is a prerequisite for shared credits, making the tool's role in the system fully comprehensible.

  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 baseline is 4. The description adds no parameter-level semantics because there are none, but it does explain the authentication flow and what happens after login. This is sufficient given 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 the tool's purpose: 'Log in to your GlassyPic account via browser to unlock more credits.' The verb 'log in' is specific and the resource (GlassyPic account) is explicit. It distinguishes itself from sibling tools like logout, status, and upgrade by focusing solely on authentication.

  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 clear context on when to use login (to unlock credits) and references the status tool for reading account tier and credits, offering an alternative for account info. It does not explicitly state when not to use login, but the use case is well implied. The mention of logout as the counterpart also helps.

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

• upgradeA
  4.7/5.0
  Behavior4/5

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

  Annotations already indicate the tool is open-world, idempotent, and non-destructive. The description adds valuable context that it opens a page (not directly modifying the plan) and that the plan can be changed from that page. This goes beyond the annotations without contradicting them.

  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 core action and then provides the usage condition. Every word earns its place with no 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?

  For a tool with no parameters and no output schema, the description is completely sufficient: it explains what the tool does, what page it opens, and when to call it. There are no gaps in understanding.

  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 the schema covers everything (100% coverage). The description still contributes by clarifying the action's intent, though no parameter details are needed. This aligns with the baseline for parameterless 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?

  The description uses a specific verb ('Open') and specifies the resource ('GlassyPic pricing page'), clearly distinguishing this from sibling tools like login, logout, status, and optimize_image. It states exactly what the tool does and why it exists.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines5/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description gives explicit when-to-use guidance: 'Call this only when the user asks to change or review their plan.' This is a clear directive that also implies when not to use it, making it easy for an agent to decide.

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

• logoutA
  4.9/5.0
  Behavior5/5

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

  The description adds concrete behavioral consequences beyond annotations: it reveals that logging out reverts to a guest session with '20 free credits/day' and that web app account remains unaffected. This aligns with the destructiveHint and idempotentHint annotations while providing valuable extra context about the state change and side effects, which annotations alone do not convey.

  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 just two sentences, front-loaded with the primary action, and every word adds value. It mentions the key outcome (guest session), a constraint (credits), and an exclusion (web app account), all in 20 words. This is exemplary conciseness.

  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 parameterless logout tool with no output schema, the description is complete: it states the action, the resulting state, and the boundary of effect. The annotations fill in the destructive and idempotent properties, and the description covers everything else an agent needs to invoke it correctly.

  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 empty schema fully covers the parameter space. Per the baseline rule, a score of 4 is appropriate since no parameter explanation is needed, and the description adds no redundant parameter details.

  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 opens with 'Log out of your GlassyPic account', a specific verb+resource that clearly states the action. It also explains the result of logging out (reverts to guest session) and explicitly distinguishes the tool's scope from a web app account, setting it apart from sibling operations like login or status.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines5/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides clear context for when to use the tool: ending a GlassyPic session. It includes an explicit when-not by stating 'Your web app account is not affected', signaling that this tool is not for logging out of the web app. The mention of guest credits hints at the post-condition, giving enough guidance for an agent to decide.

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

• optimize_imageA
  5/5.0
  Behavior5/5

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

  Discloses non-obvious behavior beyond annotations: automatic upscaling trigger (over 1.2x), per-frame GIF billing with 601 credit cap, flat 1-credit override for SVG/ICO, and default SEO tagging (on by default). No contradiction with readOnlyHint=false.

  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 dense but each sentence provides actionable details, from supported formats to credit calculations. It starts with the core action and progressively layers constraints, making it easy to scan.

  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?

  Covers input/output formats, size limits, cost model, remote mode, authentication implications, and prerequisite checks. With 12 parameters and complex billing logic, the description leaves no critical gaps for an agent to make a costly error.

  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?

  Despite 100% schema coverage, the description enriches parameters with credit costs, conditional defaults, and special cases (e.g., output_format behaviors, auto-upscale when width/height set, confirm_gif_cost gating). This goes beyond the schema's property 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 opens with a specific verb+resource: 'Optimize an image', then enumerates concrete capabilities (lossy compression, resize/upscale/format conversion, AI SEO metadata). This clearly distinguishes it from sibling tools like login, status, and upgrade.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines5/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  Provides explicit context: remote/API mode restrictions, guest vs registered credit limits, and direction to 'Use status tool to check remaining credits before batch processing'. Also explains when confirm_gif_cost is required and how to log in for more credits.

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