Server Quality Checklist

Tool Scores

• edit_imageA
  4.1/5.0
  Behavior4/5

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

  Beyond annotations (which show non-destructive, non-readonly), the description adds that inputs are processed at high fidelity and the result is saved to disk and returned inline. It does not cover rate limits or detailed auth needs, but annotations already cover safety profile.

  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 two sentences plus a list of use cases. It is front-loaded and efficient, wasting no words while providing necessary context. Slightly longer than necessary but still concise.

  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 12 parameters, full schema coverage, and an output schema, the description adequately covers the core functionality, mask usage, and behavioral notes. It does not mention session tools or rate limits, but the main points are addressed.

  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 coverage is 100%, so all parameters are documented in the schema. The description adds minimal extra parameter meaning (e.g., mask applies to first image), which is already in the schema. Baseline 3 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 'Edit or compose images with gpt-image-2' using a specific verb and resource. It lists concrete use cases (swap backgrounds, retouch, combine) and implicitly distinguishes from sibling generate_image by focusing on editing existing images.

  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?

  Provides explicit context: input 1-8 images, text prompt, optional mask. Use cases are listed, giving clear scenarios. However, it does not explicitly state when to use alternatives like generate_image or start_edit_session, though the distinction is inferable.

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

• continue_edit_sessionA
  4.2/5.0
  Behavior4/5

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

  Beyond annotations (which are sparse), the description explains the stateful behavior (each turn uses the previous output) and the return value (new image and updated session). No contradictions; adds value by clarifying the iterative process.

  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 purpose, followed by usage guidelines and return value. No extraneous information; every 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?

  Given the output schema exists, the description covers essential stateful behavior and return values. Could mention session expiry or error handling, but overall adequate for a complex tool with 9 parameters.

  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 coverage is 100%, so the schema already documents all parameters. The description adds minimal parameter-specific meaning, mostly through usage examples in prompt. Baseline of 3 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 the tool applies another edit turn to an existing session, using the previous turn's output as input. It distinguishes itself from sibling tools like start_edit_session and generate_image by specifying session-based iterative editing.

  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?

  Provides concrete advice on prompt style ('short, focused prompts') and includes tips to limit drift ('keep everything else the same'). While it doesn't explicitly state when not to use the tool or name alternatives, the context implies its iterative nature.

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

• end_edit_sessionA
  4.4/5.0
  Behavior4/5

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

  Annotations already declare destructiveHint=true and idempotentHint=true. The description adds valuable context: sessions are in-memory only, discarded on server restart, and calling the tool frees memory sooner. No contradictions found.

  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, all essential. Front-loaded with the main action, then adds usage context and benefits. No filler or 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?

  Given the simplicity (1 param, high schema coverage, output schema exists), the description covers purpose, usage, and side effects. Could mention what happens if session_id is invalid, but the idempotentHint implies safe handling.

  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 coverage is 100%. The parameter 'session_id' is well-documented in the schema with minLength and description. The tool description does not add further parameter details, which is acceptable given the schema coverage.

  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?

  Clearly states the tool ends an iterative-edit session and distinguishes from siblings like start_edit_session by noting it is optional cleanup. The verb 'Free' and resource 'iterative-edit session' are specific.

  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?

  Explicitly states when to use (to free memory sooner, keep list tidy) and when not to use (safe to skip because sessions are discarded on restart). Provides alternative: not calling the tool.

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

• start_edit_sessionA
  4.4/5.0
  Behavior4/5

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

  The description discloses the stateful nature and the iterative workflow (each turn uses previous output). Annotations already show it's not read-only, not destructive, not idempotent, and open world. The description adds context about session lifecycle but doesn't detail auth or rate limits, which are acceptable given the annotation coverage.

  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: three short sentences that convey the purpose, usage flow, and termination. Every sentence provides necessary information with no redundancy or irrelevant details.

  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 complexity (11 parameters, 2 required, output schema present), the description adequately covers the session lifecycle and key return value (session_id). It could mention the output schema or behavior on errors, but the presence of an output schema reduces the need for that in the description.

  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 description does not add parameter-specific meaning beyond what the input schema already provides (schema coverage is 100%). All parameters have individual descriptions in the schema, so the description's role is fulfilled at a baseline level without extra semantic enrichment.

  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 explicitly states 'Begin a stateful multi-turn edit session', specifying the verb 'begin' and the resource 'edit session'. It distinguishes itself from siblings like 'edit_image' (single edit) and 'generate_image' by framing it as a multi-turn iterative process.

  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 when-to-use guidance: it explains that the returned session_id is used with 'continue_edit_session' for iterative refinement and that 'end_edit_session' should be called when done. This contrasts with the sibling 'edit_image' which is for single-turn edits.

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

• generate_imageA
  4.6/5.0
  Behavior5/5

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

  The description discloses that images are written to disk and returned inline, outlines quality/compression trade-offs, rate limit implications of 'n', and the unsupported transparent backgrounds. This adds substantial context beyond the annotations (readOnlyHint=false, openWorldHint=true).

  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 the main purpose first, then capabilities, restrictions, and parameter context. While it is a bit lengthy, every sentence adds value and there is 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?

  Given the tool's complexity (11 parameters, output schema present), the description covers core functionality, constraints, default behavior, and side effects (disk write, rate limits). No gaps are apparent.

  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 already covers 100% of parameters with descriptions. The description adds extra usage guidance (e.g., using ALL CAPS for literal text, size constraints, 'background: opaque' for filled backgrounds), enhancing the schema meaning.

  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 'Generate an image from a text prompt using OpenAI's gpt-image-2 model.' It lists supported image types and explicitly mentions it does NOT support transparent backgrounds, distinguishing it from sibling editing 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 provides clear context for using the tool (text-to-image generation) and hints at when not to use it (transparent backgrounds). It does not explicitly mention sibling tools as alternatives, but given the sibling set, confusion is unlikely.

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

• list_edit_sessionsA
  4.7/5.0
  Behavior5/5

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

  Adds critical context beyond annotations: 'in-memory only, discarded on server restart' and 'active' sessions. Annotations already declare read-only, idempotent, non-destructive, but description explains ephemeral nature.

  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, no wasted words. Front-loaded with key purpose and behavior. Every sentence adds value.

  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 zero parameters and an output schema, the description fully covers what the agent needs: what the tool returns (list of sessions) and why it exists. No gaps.

  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 no parameter info, but none needed. 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?

  Description clearly states 'list active iterative-edit sessions', specifying verb, resource, and scope. Distinguishes from sibling tools like start_edit_session or continue_edit_session.

  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?

  Provides explicit use case: 'recover a session_id after a client reconnect'. While it doesn't explicitly exclude other uses, it gives clear context for when this tool is useful.

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