Server Quality Checklist

Tool Scores

• reset_recipeB
  3.1/5.0
  Behavior2/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. It states the core destructive action but does not mention irreversibility, side effects on the recipe, permission requirements, or what happens to the current state. For a reset operation, this lack of detail is a significant gap.

  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 clear sentence with no unnecessary words. It is front-loaded and immediately conveys the primary purpose and effect.

  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?

  With no annotations, no output schema, and only one required parameter, the description covers the basic action but omits crucial context such as irreversibility, relationship to the recipe, typical use cases, and side effects. An AI agent would lack important information for confident invocation.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters1/5

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

  The schema has one parameter (image_id) with 0% description coverage, and the description does not explain the parameter's role or format. Since the description fails to compensate for the low schema coverage, it provides no value beyond the raw property name.

  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 action with a specific verb ('Remove all edits') and resource ('image'), and specifies the result ('restoring the image to its unedited state'). This distinguishes it from sibling tools like update_recipe or set_recipe, which modify the recipe rather than reset the image.

  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 when to use the tool (when you want to discard all edits and revert to the original), but it does not explicitly mention usage context or alternatives. There is no guidance on when not to use it or how it compares to related tools such as set_recipe or auto_adjust.

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

• set_ratingB
  3.2/5.0
  Behavior2/5

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

  No annotations are present, so the description must carry the full burden of behavioral disclosure. It only states that the tool sets a rating and the valid range; it does not mention whether the rating overwrites an existing value, requires specific permissions, or how invalid values are handled.

  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 clear sentence, front-loaded with the action and scope. Every word contributes meaning and there is no wasted text.

  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?

  For a mutation tool with no annotations and no output schema, the description is thin. It fails to mention how the rating relates to the broader image workflow, what happens on invalid input, or any return/error behavior, leaving significant context unaddressed.

  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 schema provides no descriptions for the two parameters, and the description compensates by explaining the rating range and the meaning of 0 as unrated. However, it does not clarify the image_id parameter beyond what its name implies, leaving a partial gap.

  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 the specific verb 'Set' with the resource 'star rating' and defines the range 0-5, making it clear what the tool does. It distinguishes itself from sibling tools like set_flag and set_library by naming the rating concept.

  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 about when to use this tool versus alternatives, such as set_flag or set_recipe. There is no mention of prerequisites, context, or known alternatives, leaving the agent to infer usage from the name alone.

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

• get_recipeB
  3.4/5.0
  Behavior2/5

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

  No annotations are provided, so the description must disclose behavioral traits. It only states that the recipe is 'non-destructive' and returned as JSON, but does not confirm read-only behavior, error handling, or response format beyond 'JSON'. There is no mention of side effects or authorization.

  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, succinct sentence that directly states the tool's function without extraneous information.

  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 tool is simple, but the description lacks details about the return value's structure (only says 'JSON'), any error cases, or usage context. With no output schema or annotations, the description should offer more context but remains minimally adequate for a getter.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters2/5

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

  The schema has one parameter, image_id, with zero description coverage. The description does not explain the parameter's role or format, adding no semantic value beyond the schema's 'Image Id' title. While the parameter is self-explanatory, the description fails to compensate for the 0% coverage as required.

  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 the specific verb 'Get' and identifies the resource as 'the image's current non-destructive edit recipe (JSON)', clearly distinguishing it from sibling tools like set_recipe, update_recipe, reset_recipe, and get_recipe_schema.

  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 one needs the current recipe for an image, but it does not explicitly state when to use it versus alternatives (e.g., get_recipe_schema) or provide exclusion criteria. Sibling names are available but not referenced in the description.

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

• set_recipeB
  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 burden of disclosing behavioral traits. It mentions that omitted fields reset to defaults, which is a key behavior, but lacks details on side effects, reversibility, permissions, or return values. It adds value beyond the schema but is incomplete.

  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, front-loaded with the verb and object. It communicates the core behavior and the important reset semantics without any filler or redundant information.

  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 essential purpose is clear, and the reset behavior is disclosed, but the tool has no annotations, no output schema, and no parameter documentation. It does not cover prerequisites, return behavior, or how the recipe object should be structured, leaving notable gaps for an agent.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters1/5

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

  Schema description coverage is 0%, and the description provides no explanation of the 'image_id' or 'recipe' parameters. The recipe object is open-ended (additionalProperties), and nothing clarifies its structure or how it relates to the image. The description fails to compensate for the lack of schema documentation.

  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 verb ('Replace') and a specific resource ('entire edit recipe'), and clearly distinguishes from siblings like update_recipe and reset_recipe by emphasizing full replacement and default-resetting behavior. It is unambiguous about what the tool does.

  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 for full replacement versus partial updates via 'entire' and 'omitted fields reset to defaults,' but it does not explicitly name alternatives or provide explicit when-to-use guidance. The context gives some direction but falls short of clear exclusions or alternative recommendations.

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

• set_libraryA
  3.5/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 the full burden of disclosing behavioral traits. It states that it 'opens' a local folder and 'scans' for images, implying a state change, but it does not mention side effects like replacing the current library, required permissions, or whether the scan is recursive. For a tool that mutates the environment state, more disclosure is needed.

  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, concise sentence (14 words) that front-loads the primary action and object. There is no redundancy or unnecessary elaboration. Every word contributes to understanding the tool's core purpose.

  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?

  For a simple tool with one parameter, no annotations, and no output schema, the description provides a basic understanding. However, it is incomplete in key behavioral aspects: it does not clarify whether setting a new library replaces the previous one, what 'scan' entails (e.g., indexing, supported formats), or any return value. Given its role as a setup operation among image-related tools, more context would help the agent use it correctly.

  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 input schema has one parameter 'path' with no description. The tool description does not mention the parameter by name, but the phrase 'local folder' directly alludes to the 'path' parameter's meaning. Since schema coverage is 0%, the description adds some semantic value, but it does not specify details such as the path being a directory or whether it must be absolute. It partially compensates for the lack of schema documentation.

  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: 'Open a local folder as the photo library and scan it for images.' It uses specific verbs (open, scan) and identifies the resource (local folder, photo library). This distinguishes it from sibling tools, which focus on individual images or recipes rather than library-level setup.

  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 context: it sets the library before other operations. However, it does not explicitly state when to use this tool versus alternatives, nor does it mention any exclusions or prerequisites. For instance, it does not say 'use this before list_images' or that setting a new library replaces the existing one. The guidance is implicit rather than explicit.

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

• get_imageA
  3.7/5.0
  Behavior3/5

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

  With no annotations, the description carries the burden for behavioral disclosure. It lists the output fields, which is useful, but does not mention error behavior, read-only nature, or any side effects. The return-value disclosure is partial but present.

  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, front-loaded with the core action ('Full metadata for one image') and a concise enumeration of fields. Every word adds value; no redundancy or filler.

  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 simple one-parameter getter, the description covers the essential context: what the tool returns and the scope. It omits edge cases (e.g., not-found behavior) but is reasonably complete given the tool's simplicity, especially when no output schema is provided.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters2/5

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

  The schema has 0% description coverage for the only parameter image_id. The description only says 'for one image,' which barely reinforces the parameter's purpose. It does not explain the format, source, or how to obtain the ID, so it fails to compensate for the absent schema documentation.

  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 verb ('get') and resource ('image'), and specifies the scope ('one image') with a list of metadata fields ('path, EXIF, rating, flag, edit status'). This distinguishes it from siblings like list_images (multiple images) and get_current_image (current image, not specific).

  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 context: when you need full metadata for a single identified image. However, it does not explicitly mention when to prefer this over list_images or get_current_image, nor does it state any alternative or exclusion.

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

• list_imagesA
  3.8/5.0
  Behavior3/5

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

  With no annotations, the description carries full burden. It discloses that it returns metadata including id, but does not mention pagination behavior, default sort/limit, or explicitly state read-only nature (though 'list' implies it). Provides some value but misses richer behavioral context.

  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 core purpose and key parameter details. No waste, efficiently structured despite a line break. Each sentence earns its place.

  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 has 7 parameters and no annotations or output schema, the description is incomplete: it covers only 2 parameters, gives partial return info, and lacks context on sorting/pagination. It is serviceable but leaves gaps for an agent needing to use it correctly.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters2/5

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

  Schema coverage is 0%, so description must compensate. It explains rating_gte (0-5) and flag (pick/reject/none), but omits sort, limit, order, offset, and has_edits, leaving 5 of 7 parameters without any explanation beyond schema titles. Incomplete compensation.

  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 'List images in the library' with optional filters, using a specific verb and resource. It distinguishes itself from siblings like get_image by emphasizing it returns IDs for other tools, making its role as a listing/discovery tool evident.

  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 returns ids 'which all other tools take', implying this is the entry point before using other tools. However, it does not explicitly name alternatives or provide when-not-to-use guidance, so it falls short of a full 5.

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

• get_recipe_schemaA
  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 transparency burden. It states the schema is 'full' and includes 'all parameters and ranges,' which clarifies scope. However, it doesn't explicitly state read-only behavior or any side effects, though 'get' implies read-only.

  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, efficiently worded sentence that front-loads the core purpose without extraneous detail.

  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, no output schema, no annotations), the description is sufficient to understand what the tool returns. It doesn't provide additional context about use cases, but none is strictly necessary.

  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 description need not explain parameter details. The schema is empty, and the baseline for zero parameters is 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 identifies the tool as providing the full JSON Schema for edit recipes, specifying the exact resource and scope. It distinguishes from sibling tools by focusing on the schema rather than actual recipe operations.

  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?

  No explicit guidance is given on when to use this tool versus alternatives, but the description implies it is for obtaining schema information. It does not mention exclusions or contrast with get_recipe, so usage context is only implied.

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

• render_previewA
  4/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 side effects. It states output is a JPEG and that current edits are applied, implying read-only preview, but doesn't explicitly declare non-destructive behavior or resource requirements. This leaves some ambiguity about whether the operation mutates 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?

  The description is two short sentences, immediately front-loaded with the action and purpose. Every sentence adds value 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 simple 2-parameter preview tool, the description covers the return format (JPEG), the size parameter semantics, and the preview context. It lacks an explicit note about non-destructiveness, but overall it provides sufficient guidance for basic usage.

  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 description adds semantic meaning for 'size' as 'longest edge in px (256-4096)', which is not in the schema. It doesn't elaborate on image_id, but its purpose is self-evident from context; this adequately compensates for the schema's 0% 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?

  The description clearly specifies 'Render the image WITH its current edits applied and return the JPEG' — a specific verb and resource with scope. It distinguishes from siblings like get_image or export_image by emphasizing 'visually inspect' as a preview purpose.

  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 for inspecting intermediate results after edits, but doesn't explicitly state when not to use or name alternatives like export_image. The size range information suggests configuration, but not when to prefer this over other tools.

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

• set_flagA
  4/5.0
  Behavior3/5

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

  No annotations are provided, so the description carries the full burden of behavioral disclosure. It does explain the flag values and that None unflags, but it does not mention side effects, permissions, overwriting behavior, or return values. This is adequate for a simple setter but lacks depth.

  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 concise sentence that is front-loaded with the action and resource. It avoids unnecessary detail while conveying the key 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?

  Given the tool's simplicity and the schema's clarity, the description is complete enough for an agent to invoke it correctly. It covers the main behavior (set/unset flag) and parameter semantics. It does not elaborate on consequences or error conditions, but these are not critical for a basic flagging operation.

  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 schema provides no descriptions for parameters (0% coverage), so the description must compensate. It adds meaning by explaining the flag values and the semantics of None (unflag), which is not obvious from the schema alone. The image_id is self-explanatory, so no further detail 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's purpose: flag an image as 'pick' or 'reject', or unflag with None. It uses a specific verb and resource and distinguishes from sibling tools like set_rating by focusing on flagging specifically.

  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 when to use the tool—when you want to flag an image—but does not explicitly mention alternatives or exclusions. Sibling tools like set_rating exist, but the description does not state when to prefer set_flag over them, leaving the agent to infer.

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

• auto_adjustA
  4.2/5.0
  Behavior4/5

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

  With no annotations provided, the description carries the burden of explaining behavior. It discloses that the tool modifies whiteBalance/tone/vibrance, preserves existing detail and geometry settings, and returns the new recipe rather than saving it directly. This is useful and non-obvious behavior, though it does not mention potential side effects like overwriting previous values or needing permissions.

  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 that pack in the core behavior, what is preserved, the return value, and a follow-up instruction. No wasted words, and key information is front-loaded with the tool's purpose.

  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 output schema and no annotations, the description covers the essential aspects: what the tool does, what it changes, what it preserves, what it returns, and how to use the result. It does not explain failure modes or parameter details, but for a recipe-adjustment tool this is reasonably complete for an agent to use it correctly.

  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 descriptions are completely absent for the two parameters, so the description must compensate. It indirectly explains image_id by saying 'analyzes the image' and links white_balance to 'gray-world WB', but it does not explicitly state what the boolean white_balance parameter does (e.g., whether false disables white balance adjustment). The parameter meanings are inferable but not directly spelled out.

  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 identifies the tool as a computational auto-adjust that analyzes an image and sets white balance, tone, and vibrance. This distinguishes it from sibling tools like update_recipe or set_recipe, which are manual recipe adjustments, by emphasizing the automatic, analysis-driven nature.

  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 an explicit workflow hint: 'render_preview afterwards to judge the result.' This tells the agent when to use it relative to the sibling tool render_preview. It does not explicitly rule out alternatives, but the context suggests it is for automatic adjustments rather than manual recipe editing.

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

• export_imageA
  4.5/5.0
  Behavior4/5

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

  With no annotations provided, the description carries full responsibility for behavioral disclosure. It clearly states the output format (sRGB JPEG), explains the effects of quality (1-100), max_dimension (resize longest edge), and path (override default destination), and notes the return value (written file path). It does not mention overwrite behavior or prerequisites (e.g., whether the image must be edited), but the essential behavioral traits are covered.

  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 sentences, front-loaded with the primary purpose, and uses compact, information-dense phrasing. Every clause adds value: format, parameter effects, and return value. 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 tool has 4 parameters, no annotations, and no output schema, the description covers the main inputs and return value. It also references the library destination, tying to the set_library sibling. It omits potential error behaviors or whether existing files are overwritten, but for a straightforward export tool, it is reasonably complete.

  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 description coverage is 0%, so the description must fully explain the parameters. It provides meaningful semantics for quality (range 1-100), max_dimension (resizes longest edge), and path (overrides default destination). image_id is implicit from context, and the description adds clarity that would otherwise be missing from the schema alone.

  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 'Export the edited image as an sRGB JPEG', using a specific verb and resource with clear output format. This distinguishes it from sibling tools like render_preview (preview) and set_recipe (recipe management), making the tool's purpose unambiguous.

  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 when to use the tool (when exporting an edited image to JPEG) and lists parameters that affect the output. It does not explicitly name alternatives or state when not to use it, but the context of siblings (e.g., render_preview for on-screen preview) makes usage clear. No exclusions are stated, so it earns a 4.

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

• update_recipeA
  4.5/5.0
  Behavior4/5

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

  Even without annotations, the description discloses the partial merge behavior, field ranges, and constraints. It states unspecified fields keep their values, explaining the merge semantics. It does not explicitly mention side effects like permanent modification or return values, but 'edit recipe' implies mutation.

  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 well-structured with clear sections and bullet points for each recipe category. The length is justified by the complexity of the patch object, and every sentence adds value.

  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?

  The description covers the complex input structure comprehensively and references get_recipe_schema for full schema details. It does not specify the return value or error handling, but given the complexity and lack of output schema, it is quite complete.

  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?

  The input schema only shows image_id and patch (additionalProperties), but the description thoroughly documents all nested fields with units, ranges, and an example. This fully compensates for the 0% schema coverage and adds significant 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 the tool's function: merging a partial recipe into the image's edit recipe, described as 'the usual way to edit'. This distinguishes it from siblings like set_recipe by emphasizing partial updates.

  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 how to use it ('only supply fields you want to change') and implies it is the standard editing tool. However, it does not explicitly mention when to avoid it or use alternatives like set_recipe or reset_recipe, lacking explicit exclusions.

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

• get_current_imageA
  4.7/5.0
  Behavior4/5

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

  No annotations are provided, so the description carries the burden. It discloses an important behavioral trait: returns null if nothing is selected. It also clarifies the state dependency ('currently has selected/open'), which is valuable for an agent to understand potential null results.

  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 concise sentences. The first states what the tool returns, including the null case, and the second gives usage guidance. No wasted words.

  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 zero-parameter tool with no output schema, this description fully covers purpose, behavior, and usage. It explains the return value (image id or null), the context (current selection in Viberoom UI), and when to use it. Nothing essential is missing.

  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 zero parameters, so the baseline score is 4. The description adds no parameter information because none exists, which 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 returns the currently selected/open image from the Viberoom web UI, with the verb implied by the name 'get'. It distinguishes itself from get_image (which presumably gets by ID) and list_images by focusing on the current selection context.

  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 guidance: 'Use this when the user says "this image" / "my current image"'. This gives a clear trigger for when to invoke this tool, which is sufficient for a simple tool with no alternatives needed.

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