Server Quality Checklist

Tool Scores

• delete_template_setB
  3.4/5.0
  Behavior3/5

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

  With no annotations provided, the description carries the full burden of behavioral disclosure. 'Permanently deletes' effectively communicates irreversibility, which is a key behavioral trait. However, it does not disclose potential side effects, whether confirmation is required, or what happens to associated resources—though for a simple delete-by-id tool this may be sufficient.

  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 direct and front-loaded. Every word contributes: 'permanently' conveys irreversibility, 'deletes' the action, 'saved style preset' the target. There is no redundant or filler content.

  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 has low complexity (one parameter, no output schema, no annotations), and the description covers the core operation and permanence. However, it leaves the parameter 'id' undefined and does not clarify whether 'style preset' is exactly synonymous with 'template set'. For an agent to call it correctly, the missing parameter semantics are a notable gap.

  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 input schema has one required id parameter with 0% description coverage, so the description must compensate. The description does not explain what 'id' refers to or what format is expected. While it is inferable that id identifies the template set, the description itself adds no meaning beyond the 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 states a specific verb ('deletes') and resource ('saved style preset'), clarifying that this is a destructive operation. The title 'Delete a saved template set' aligns with sibling tools like create_template_set, making the 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 Guidelines2/5

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

  The description does not provide any guidance on when to use this tool versus alternatives. It does not mention related tools such as list_template_sets or create_template_set, nor does it specify any prerequisites (e.g., that the template set must exist). The usage context is only implied by the tool name and title.

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

• list_template_setsA
  3.5/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 burden. It does disclose that the operation is account-scoped and returns all saved style presets, but it says nothing about response format, pagination, ordering, or how 'saved' differs from 'ready.' 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 a single sentence with no filler. It front-loads the verb and resource, and the parenthetical cross-reference to create_template_set is a useful navigation hint without adding bulk.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a zero-parameter read-only list tool with no output schema, 'Lists every style preset saved on this account' is mostly complete. The main gap is clarifying how this relates to list_ready_template_sets and what exactly constitutes a style preset, so it is not quite a 5.

  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 already covers everything needed. The description's account-scope wording adds no parameter semantics, but none are required; the zero-parameter baseline of 4 applies.

  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 uses a specific verb ('Lists') and a clear resource ('every style preset saved on this account'), making the core action unambiguous. It does not explicitly differentiate from the similar sibling list_ready_template_sets, and it uses 'style preset' while the title says 'template sets,' so it stops short of a 5.

  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 given about when to use this tool instead of list_ready_template_sets or other list siblings. The parenthetical reference to create_template_set is a cross-reference, not a usage condition or exclusion.

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

• get_ready_template_setA
  3.6/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 behavioral disclosure. It does disclose the key return characteristic (shots with ids usable by create_catalog_job), but does not mention failure behavior, authentication, or what other fields the entry contains. Adequate but with gaps.

  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?

  A single sentence that front-loads the core action, then adds the most useful downstream detail. 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.

  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 without an output schema the description does partially cover the return value. However, it leaves the id parameter undefined and does not give usage alternatives, so the agent still needs to infer important context from sibling names.

  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 parameter id is only typed as string with 0% coverage, and the description never explains that id identifies which ready-made set to fetch. It is inferable from context, but the description adds no direct meaning beyond the 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 states a specific verb ('Fetches') and resource ('one entry from Fashio's curated photoshoot library'), and clarifies what is included (shots). This clearly distinguishes it from list_ready_template_sets, which would return multiple entries.

  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 retrieving a single ready-made set and even connects it to create_catalog_job, but it does not explicitly mention when not to use it or name the sibling list_ready_template_sets as the alternative for selecting a set. Guidance is present but mostly implicit.

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

• create_template_setA
  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 the behavior burden. It clearly implies persistence by 'Saves... as a named preset' and clarifies that the garment is not captured ('NEW garment'). However, it does not disclose overwrite/collision behavior, permissions, or the response shape.

  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, and free of filler. The dense field list is justified because it tells agents exactly what gets persisted.

  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 an 8-parameter tool with a nested object, no annotations, and no output schema, this is incomplete. The description presents sourceMediaId as the only path, leaving the images+toolId path to schema hints, and never states what the tool returns.

  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 adds useful meaning by grouping the captured styling fields and linking sourceMediaId to a completed generation. But it omits the alternative images+toolId construction path entirely, and with 50% schema coverage it does not fully compensate for undocumented parameters like pose, ratio, shotType, and stylePreset.

  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 names a specific action ('Saves... as a named preset'), a specific input ('from a completed generation (sourceMediaId)'), and the exact fields captured. It also differentiates this from create_generation by explaining how the saved preset is reused via templateSetId.

  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?

  It gives a clear workflow: use this after a completed generation, then use the resulting templateSetId in create_generation with a new garment. It does not explicitly list when-not-to-use or contrast with list/delete template set siblings, so it falls just short of an explicit routing guide.

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

• list_venuesA
  3.8/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 behavioral burden. 'Browse' reasonably implies a read-only operation, and the connection to images.venue adds practical context. However, it does not disclose response shape, ordering, or other list behavior beyond the limit parameter already documented in 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?

  One short sentence delivers the key information: the action, the resource, and the downstream purpose. There is no filler, and the most important context is front-loaded.

  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 one-parameter optional-parameter list tool, the description is functionally sufficient: agents know what to call, why, and how the result is used. It lacks explicit return-shape information, but no output schema exists and the schema already documents the limit parameter.

  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 only parameter, limit, is already described as 'Max results (default 20).' The description adds no parameter-specific meaning, so the high-coverage baseline applies.

  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 states a clear verb and resource: it browses the catalog of venues/backgrounds. It also ties the tool to a concrete use case, 'to use as images.venue in create_generation,' which clarifies its role. It does not explicitly contrast with sibling list tools, so it stops short of full differentiation.

  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 clear context for when to use this tool: before calling create_generation, to select a valid venue. It does not provide explicit exclusions or name alternative sibling tools, but the integration hint is sufficient for a simple list operation.

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

• list_ready_template_setsA
  3.9/5.0
  Behavior3/5

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

  With no annotations, the description carries the behavioral disclosure burden. It does add useful context: this is a read-only browse of curated, not user-owned, content. However, it does not disclose pagination behavior, response shape, filtering semantics, or any side effects—though 'Browse' implies a safe list operation.

  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 focused sentence with no filler. It front-loads the core purpose, uses an em-dash for the key exclusion, and ends with a practical workflow note. Every clause earns its place.

  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?

  Given 12 parameters, no annotations, and no output schema, this description is not complete enough. It orients the agent to the tool's purpose and relationship to siblings but does not explain filter meanings, paging via startAfter, defaults, or what the response contains, leaving significant room for incorrect invocation.

  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 description coverage is only 17%, so the description must compensate for undocumented parameters, but it does not. It explains the structure of the catalogue but gives no guidance for mood, sort, type, limit, gender, palette, setting, category, lighting, or featuredOnly. The example's structural hint is too indirect to count as parameter semantics.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description states a specific action ('Browse') and a specific resource: Fashio's curated ready photoshoot catalogue, including composition details (one model + one venue + N pinned poses). It explicitly distinguishes itself from list_template_sets, making sibling differentiation immediate and unambiguous.

  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 explicitly says this is NOT for the caller's own saved presets and points to list_template_sets as the alternative for those. It also recommends pairing with create_catalog_job, giving a clear workflow context for when to use this tool.

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

• create_catalog_jobA
  4/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 full behavioral burden. It discloses that the job is billed per shot, that completion requires polling, and that resultUrls will hold all outputs once finished. It is transparent about the core runtime contract, though it does not cover failure modes or permission/credit implications.

  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 tight sentences with the main action and scope front-loaded. Billing, async polling, and result-location facts are each delivered in compact clauses without 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 5-parameter tool with no output schema and no annotations, the description covers the operation, set selection, polling, and result location. Optional parameters like ratio and modelId are left mostly to the schema, but the essential invocation path is complete enough for an agent to act.

  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 80%, so most parameters are already documented and the description does not need to compensate. It reinforces shotIds as a subset mechanism and images as product photo(s), but it adds no real detail for undocumented fields like ratio. This is adequate but does not go beyond the 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 names a specific operation (running product photos through a ready-made photoshoot set), a bounded resource (Fashio's curated sets), and a concrete outcome (one image per shot). By referencing list_ready_template_sets and get_generation, it clearly separates this tool from single-generation siblings like create_generation.

  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 implicitly walks the agent through a flow: pick a set via list_ready_template_sets, submit the job, then poll get_generation. However, it never explicitly states when to prefer this tool over create_generation or any other alternative, and it offers no 'do not use when...' conditions beyond the inherent per-shot cost.

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

• list_fashion_modelsA
  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 disclosure burden. It conveys a read-only browsing behavior and that models are 'selectable' for a specific field, which is useful. However, it does not mention pagination behavior, ordering, or what kind of identifiers/fields are returned beyond the schema-provided limit and gender filter.

  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, tightly constructed sentence. It front-loads the catalog action and immediately adds the cross-tool usage context, with no redundant or filler words.

  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 low complexity, optional parameters, and full schema coverage, the description is nearly complete. It ties the tool to a downstream field in create_generation, though it could be slightly more explicit about the shape or identity of the returned model values.

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

  Parameters3/5

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

  Schema description coverage is 100%, so the baseline applies and the schema already documents limit and gender. The description adds no parameter-level meaning beyond stating the broader purpose of the returned models.

  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 names a specific verb ('Browse') and resource ('catalog of AI person models'), and explicitly ties the output to a concrete use case: 'use as images.fashion_model in create_generation.' This clearly distinguishes it from sibling list tools like list_models or list_poses.

  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 clear context for when to use the tool: when choosing an AI person model to pass as images.fashion_model in create_generation. It does not explicitly name alternatives or state when not to use it, but the purpose is specific enough to route an agent correctly.

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

• list_posesA
  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 carry the behavioral burden. 'Browse' and 'catalog' imply a read-only listing with no side effects, and linking to create_generation clarifies the output's role. However, it does not disclose auth expectations, pagination behavior, or the shape of what is returned, so transparency is only partial.

  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?

  One tightly worded sentence with the purpose front-loaded and no filler. It avoids repeating schema details and earns its place by supplying the integration context.

  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?

  This is a low-complexity catalog listing with two optional parameters fully documented in the schema. The description supplies the crucial integration context and enough of the selection purpose. Without an annotations block or output schema, a brief note on the returned values would have rounded it out, but nothing essential is missing for correct invocation.

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

  Parameters3/5

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

  Schema description coverage is 100%, so the description need not restate parameter details. It adds the useful context that returned poses are meant for the `pose` field of create_generation, which meets baseline without adding extra syntax or format information.

  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?

  States a specific action ('Browse the catalog of poses') and ties it directly to a downstream use ('to use as `pose` in create_generation'). The resource is unambiguous, and among the list_* siblings this is the only pose-specific listing, so it stands apart without needing an explicit exclusion.

  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?

  Gives a clear context: this is the tool to browse pose values before calling create_generation. It does not name alternatives or say when not to use it, but the integration with create_generation is explicit enough to guide selection among sibling list tools.

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

• get_generationA
  4.2/5.0
  Behavior4/5

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

  No annotations are provided, so the description carries the full burden. It discloses the polling behavior and the terminal statuses ('completed' or 'failed'), which is the core behavioral trait. It does not describe response format or error semantics, but for a simple status checker this is adequate.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  Two short sentences carry all needed information: what the tool does and how to use it. There is 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 one-parameter poll endpoint with no output schema, the description provides sufficient context: the id origin and the polling loop with terminal conditions. Minor omissions like return value shape or polling interval do not prevent correct invocation.

  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 already fully describes the only parameter, 'id', as 'The id returned by create_generation.' The description reinforces this source, but adds no new semantic detail beyond the schema. Baseline of 3 applies due to 100% 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?

  Description clearly identifies the action ('Checks the status of a job') and links it to a specific resource ('a job started with create_generation'). This makes the tool easily distinguishable from sibling creation and listing 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 when to use the tool: after calling create_generation, and it gives an explicit polling pattern until terminal status. It does not explicitly state when not to use it or name alternatives, but the context is strong.

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

• list_modelsA
  4.2/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 burden. It indicates a read-only listing behavior and discloses the returned content, but it does not mention auth requirements, rate limits, or whether the list is dynamic/static. 'Lists' implies no mutation, but more explicit behavioral context would be stronger.

  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 efficient sentence that front-loads the key action and resource, then packs the output contents into a compact phrase. There is no redundancy or wasted wording.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a zero-parameter list tool without an output schema, the description adequately explains what is returned: valid toolIds, input shapes, and fallback diamond prices. It is not exhaustive about response formatting, but it is sufficient for an agent to know what to expect.

  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?

  This tool has zero parameters and schema coverage is 100%, so there is nothing for the description to add about parameters. The baseline of 4 applies because no parameter ambiguity exists.

  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 ('Lists') and resource ('every valid toolId for create_generation'), and specifies the returned content: input shape and fallback diamond price. This clearly distinguishes it from sibling tools like list_fashion_models or list_poses.

  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 phrase 'for create_generation' indicates the intended use: call this tool to discover valid toolIds before invoking create_generation. It does not explicitly name alternatives or exclusion conditions, but the context is clear enough for an agent to select it.

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

• get_accountA
  4.3/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 full behavioral burden. It clearly frames the operation as a read-only retrieval by saying 'Returns...' and identifies the authentication context (the account owning the API key). It does not discuss error handling or rate limits, but for a zero-parameter getter this is sufficient.

  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?

  A single well-structured sentence that front-loads the action and lists the exact returned fields. Every word 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?

  For a simple account-info getter with no parameters and no output schema, the description fully specifies what the agent can expect: email, plan, diamond balance, and renewal date. No additional information is needed to invoke the tool 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?

  There are zero parameters, so the baseline is 4. The description correctly indicates that the identity is derived from the API key itself, which is meaningful context beyond 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 uses a specific verb ('Returns') and a clear resource ('account that owns this API key'), and enumerates the exact data fields returned. It is immediately distinguishable from sibling tools, which are all about models, templates, generations, and catalog jobs.

  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: whenever you need account-level billing or plan information associated with the API key. However, it does not explicitly state when not to use it or name any alternative, though no account-related sibling exists.

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

• upload_imageA
  4.5/5.0
  Behavior4/5

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

  With no annotations present, the description carries the behavioral disclosure burden. It discloses accepted formats, max file size, source location, and the output contract (a URL for create_generation). It doesn't mention URL expiry or storage persistence, but for a simple upload tool this is adequate.

  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?

  A single, well-structured sentence that front-loads the action and key constraints, then immediately connects the output to its downstream use. No filler or redundant explanation.

  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 one-parameter tool with no output schema, the description covers everything needed to call it correctly: accepted formats, size limit, source path, and the purpose of the returned URL. The integration with create_generation provides important surrounding context.

  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?

  Schema coverage is 100% and already indicates the filePath is an absolute path to a local image. The description adds the 8MB size cap and reinforces accepted formats, providing marginal but real meaning beyond the 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 action (Upload), the resource (a LOCAL image file), and the purpose (returns a URL usable in create_generation's images.* fields). It differentiates itself from the create_generation sibling by positioning upload as a prerequisite feed for that tool.

  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: use it to convert a local filesystem image into a URL for create_generation. While it doesn't explicitly say 'use this instead of X', there are no uploader sibling tools, so the integration context is sufficient.

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

• create_generationA
  4.6/5.0
  Behavior4/5

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

  With no annotations, the description carries the full behavioral burden. It discloses the key side effect: 'Deducts diamonds from the account that owns the API key,' and the asynchronous behavior: returns with status 'processing' and requires polling. It does not cover error or failure behavior, but the most important operational risks are stated.

  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?

  Four sentences deliver the core action, cost, prerequisite, async workflow, and template alternative with no filler. The most important operational facts are front-loaded, and 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?

  For a complex 13-parameter creation tool with nested objects and no output schema, the description covers the main workflow and conditional parameters. It omits the exact response identifier and failure/error semantics, but the schema handles per-parameter details and the description points to the right sibling tools for prerequisites and polling.

  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 already provides 100% coverage of all 13 parameters, so the baseline is 3. The description adds value beyond the schema by explaining that toolId validity and images requirements come from list_models, and that templateSetId fills in multiple style-related defaults. This cross-tool context makes parameter selection easier.

  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 starts with a specific verb and resource: 'Starts an AI fashion generation job.' It clearly differentiates this creation tool from the polling tool by stating 'Returns immediately with status processing — poll get_generation for the result.' This makes the tool's role in the workflow unambiguous.

  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 explicitly says to call list_models first for valid toolId values and required images keys, and to poll get_generation for the result. It also offers a clear alternative: pass templateSetId instead of manually choosing fashion_model/venue/pose. This directly guides tool selection and invocation order.

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