Server Quality Checklist

Tool Scores

• list_framesC
  2.8/5.0
  Behavior2/5

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

  No annotations are provided, so the description carries the full burden. It only states it lists text frames, but does not disclose return format, side effects (likely read-only but unstated), or behavior when scope='selection' (e.g., requires an active selection). It adds no insight beyond the parameter schema.

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

  Conciseness3/5

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

  The description is a single concise sentence, appropriately sized for a simple listing tool, but it is under-specified. It omits important context like the selection scope and return details, so it is brief but incomplete rather than efficiently complete.

  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 no output schema and no annotations, the description should explain what the tool returns (e.g., frame references for use with other tools) and any prerequisites. It fails to mention the 'selection' scope, relationship between parameters, or the tool's role in a workflow, leaving the agent with an incomplete picture.

  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 documents both parameters with descriptions and an enum for scope, so the baseline is 3. The description adds only a restatement of 'page or document' but does not clarify the interaction between page and scope (e.g., page is ignored unless scope='page') or the meaning of the 'selection' option, which the schema covers, so it adds minimal extra value.

  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 ('Lists') and a specific resource ('all text frames') with a scoping qualifier ('on a page or in a document'). It distinguishes the listing operation from sibling tools like get_text or create_text_frame, though it omits the 'selection' scope that the schema supports, creating a minor gap.

  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. With many siblings (get_text, insert_text, etc.), the description does not clarify that list_frames is for enumerating frames rather than reading content or manipulating them, leaving the agent to infer usage context.

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

• export_imageC
  2.9/5.0
  Behavior2/5

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

  With no annotations, the description must carry the full behavioral burden, but it only states the core export action. It omits critical behavior such as whether existing files are overwritten, whether it modifies the source document, or how it handles output directories—details that the 'overwrite' parameter hints at but the description fails to address.

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

  Conciseness5/5

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

  The description is a single, front-loaded sentence that efficiently communicates the primary function. It avoids unnecessary words and gets straight to the point, making it easy to parse quickly.

  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 the tool has 7 parameters, multiple sibling export tools, and no output schema or annotations, the description is too sparse to be considered complete. It lacks guidance on when to choose this tool, what the output looks like, and behavioral nuances, leaving a capable agent without enough context to invoke it correctly in all scenarios.

  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 documents all 7 parameters with descriptions, so the coverage is 100%. The description adds no extra meaning to any parameter, but since the schema is exhaustive, the baseline of 3 is appropriate; the description neither enhances nor contradicts the schema.

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

  Purpose4/5

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

  The description clearly states the action ('Exports document pages') and specifies the output formats (JPG, PNG, TIFF), making the purpose unambiguous. It differentiates from the sibling 'export_pdf' by format, but it does not explicitly distinguish itself from other export-related siblings like 'batch_export' or 'quick_export'.

  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 provides no guidance on when to use this tool versus the other export tools in the sibling list. It does not mention any conditions, prerequisites, or alternatives, leaving the agent without context to choose the appropriate tool.

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

• get_document_infoC
  2.9/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 burden of behavioral disclosure. It only says 'Gets detailed information,' which implies a read operation, but it does not state whether the tool modifies anything, what 'detailed information' includes, whether it requires an open document, or how errors 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.

  Conciseness4/5

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

  The description is a single, direct sentence with no filler or redundant wording. It is concise and front-loaded, though it omits substantive details that would make it more helpful.

  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?

  The tool has no output schema and no annotations, but the description does not explain what 'detailed information' consists of or what the agent should expect in the response. Since the schema covers the only parameter well, the main gap is the lack of return-value or behavioral context.

  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% for the single parameter, and the schema already explains 'document' with an example and the special 'active' value. The tool description adds no extra meaning beyond what the schema provides, so a baseline score of 3 is appropriate.

  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 specific action ('Gets detailed information') and a clear resource ('an InDesign document'), making the tool's core purpose understandable. It does not explicitly distinguish itself from siblings like list_documents or get_page_info, but the 'document' vs 'page' distinction is reasonably inferable.

  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 versus alternatives such as list_documents or get_page_info. There are no exclusions, prerequisites, or usage conditions beyond what the parameter schema implies.

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

• get_page_infoC
  2.9/5.0
  Behavior2/5

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

  With no annotations provided, the description must convey behavioral traits, but it only implies a read-only operation ('Gets') and offers no detail on side effects, error conditions, pagination, or output format. It fails to disclose what 'detailed information' actually contains.

  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 filler. It is appropriately concise for a tool with one parameter and a straightforward purpose.

  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 the absence of an output schema, the description should at least indicate what kind of information is returned (e.g., page dimensions, elements present, or metadata). The current text leaves the agent uncertain about the tool's capabilities, making it incomplete despite the tool's apparent simplicity.

  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 covers 100% of the single parameter 'page' with a description and default. The tool description adds no supplementary meaning beyond that, so the baseline of 3 applies. It neither enriches nor misleads regarding parameter use.

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

  Purpose4/5

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

  The description clearly states the verb 'Gets' and the resource 'page', indicating it retrieves information about a single page. It is distinct from siblings like list_documents or get_document_info, though it does not explicitly name an alternative. However, 'detailed information' is vague and leaves the exact scope ambiguous.

  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 on when to use this tool versus alternatives such as get_document_info or list_frames. The description lacks any context about prerequisites, typical use cases, or conditions that would make this tool the right choice.

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

• get_textC
  2.9/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 does not mention side effects (though likely none), permissions, return format, or any constraints like requiring an active document. It simply says 'reads text' without elaborating on what happens for each target or whether the operation is safe.

  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 a single sentence and is concise, but it includes an inaccurate reference to 'paragraphs' which is not a target option, and it omits the 'document' and 'selection' targets present in the enum. Still, it is front-loaded with the main action and resource, making it reasonably efficient.

  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 multiple targets and no annotations or output schema, the description is minimal. The schema provides parameter details, but the description does not clarify how the tool behaves with each target (e.g., what happens when target=frame with no frameIndex, or how selection is determined). It is functional but leaves the agent to infer details from schema and sibling infos.

  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%, and each parameter (target, page, frameIndex) has its own description in the schema. The tool description adds the word 'paragraphs' which does not correspond to any enum value, but otherwise provides no additional meaning beyond the schema. Baseline 3 is appropriate since the schema already documents parameters thoroughly.

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

  Purpose4/5

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

  The description clearly states the tool reads text and lists some target types (frames, paragraphs, pages) with a specific verb 'reads'. However, the target enum in the schema includes 'selection', 'document', and 'frame' – 'paragraphs' is not an option, and 'document' and 'selection' are omitted from the description, creating slight misalignment. It still distinguishes from write tools like insert_text and replace_text.

  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 on when to use this tool versus siblings like list_frames or get_document_info. There is no explicit mention of prerequisites, alternatives, or conditions for selecting a specific target. The description only implies a read operation without context on when it is the best choice.

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

• quick_exportC
  2.9/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 behavioral disclosure. It only says 'exports' without mentioning whether files are overwritten, whether the operation opens dialogs, whether it requires a saved document, or what happens on failure. For a tool that writes an output file, this is a meaningful gap.

  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 a single short sentence that gets to the point quickly. The word 'Quickly' adds a minor usability flavor but is somewhat redundant; overall the size is appropriate for the function.

  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 output schema and no annotations, the description should compensate by explaining format-specific behaviors, conditional parameters, and expected results. The current description is too sparse: it does not mention that pageRange and resolution apply only to images, that pdfPreset is PDF-only, or what the tool returns after export.

  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 covers all parameters with descriptions and an enum for format, so the baseline is 3. The description adds no additional parameter-level meaning, but the schema already provides sufficient detail for parameter understanding.

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

  Purpose4/5

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

  The description clearly states the action ('exports'), the resource ('active document'), and the destination ('a specific format'). It is more specific than a tautology, but it does not explicitly distinguish itself from sibling tools like export_pdf, export_image, or batch_export, so the differentiation is left for the agent to infer.

  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 gives no guidance on when to choose quick_export over alternatives such as export_pdf, export_image, or batch_export. There is no statement about conditions, exclusions, or trade-offs, leaving the agent without sufficient context for tool selection.

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

• replace_textC
  2.9/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 carry the burden of behavioral disclosure. It only states the operation without mentioning destructiveness, undo capability, scope limitations, or effect on formatting. It also fails to specify whether it replaces all occurrences or just the first, or how it handles no-match cases.

  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?

  Single concise sentence that gets straight to the point with no wasted words. It is front-loaded with the core action and scope, which is appropriately minimal for a straightforward tool.

  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?

  The description is too minimal for a document-modifying tool. It doesn't mention return value, error cases, or behavioral details like case sensitivity default (though schema has it), scope handling, or impact on existing text. The schema provides parameter info but not the operational context an agent needs to anticipate side effects.

  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 covers all parameters with descriptions (100% coverage). The description adds no additional parameter context, so baseline 3 is appropriate. The description does not elaborate on parameter semantics beyond what the schema already provides.

  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?

  Description clearly states the action (replaces) and target (text in active document). It is specific enough to distinguish from insert_text (which inserts new text) and get_text (which reads). However, it doesn't explicitly name siblings or differentiate further beyond the basic verb-resource pair.

  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 on when to use this vs alternatives like insert_text or set_frame_text. The description only states what it does, not when to choose it over other text-editing tools, nor any conditions or prerequisites.

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

• set_frame_textC
  2.9/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. It reveals a mutation intent ('sets or appends') but does not disclose what 'set' means (replace all text?), whether append/prepend are position-based, or any side effects (e.g., affects other frames). It also omits error behavior or permission requirements. This is insufficient for a mutation tool.

  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 a single, concise sentence that is front-loaded with the action and resource. It wastes no words, but it omits useful context that could be added without lengthening much (e.g., behavior of modes). Effective but slightly under-informative for the complexity.

  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 output schema and four parameters, the description does not explain what happens on success (return value, UI update), how 'set' differs from 'append' behaviorally, or any constraints (e.g., document must be open, frame existence). The schema covers param syntax but not runtime semantics, leaving gaps for an agent.

  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 all parameters are documented structurally. The description adds no extra meaning beyond the tool's purpose and does not explain how mode values (replace/append/prepend) interact with the text. Baseline of 3 is appropriate since the schema does the heavy lifting, and the description adds minimal value.

  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 ('sets or appends') and resource ('text frame'), and the mention of mode clarifies the action. However, it doesn't explicitly differentiate from siblings like insert_text or replace_text, which could cause confusion about which tool to use. It is specific about targeting a frame but not about how the frame is selected (page/index).

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

  Usage Guidelines2/5

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

  No guidance is provided on when to use this tool versus alternatives like insert_text, replace_text, or get_text. The description does not mention prerequisites (e.g., an open document) or any exclusions. The agent must infer usage from the name and siblings, which is weak.

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

• apply_styleB
  3.2/5.0
  Behavior2/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 states 'applies' indicating mutation, but it does not explain side effects (e.g., what happens to existing formatting), error conditions (e.g., nonexistent style), or return values. It does not mention any required permissions or whether changes are reversible. For a mutation tool with no annotations, this 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 short sentence with no redundancy. It front-loads the core action and objects. Every word earns its place, making it highly concise and well-structured.

  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 the tool has 5 parameters, no output schema, and no annotations, the description is inadequate. It fails to mention prerequisites (e.g., an open document), error behavior (e.g., when style doesn't exist), or the effect on existing formatting. The schema fills parameter details, but the description lacks operational context that an agent needs to call the tool correctly, such as whether it applies to the current document or requires specific selections. This is insufficient for a mutation tool.

  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 covers 100% of parameters with descriptions, so baseline is 3. The description adds minimal value beyond the schema: it mentions 'paragraph or character' and 'selected text or a frame' which map to styleType and target, respectively. However, it does not explain the purpose of page, frameIndex, or nuance of styleName. Since the schema already describes these, the description's contribution is marginal, keeping it at baseline 3.

  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 'applies' and the object: paragraph or character style to selected text or a frame. This distinguishes it from sibling tools like list_styles (which lists styles) and set_frame_text (which sets text content). The purpose is specific 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 Guidelines2/5

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

  The description gives no guidance on when to use this tool versus alternatives, nor any exclusions or prerequisites. It implies usage for applying styles but does not mention when not to use it (e.g., for listing styles, use list_styles) or any required context (e.g., open document, existing style). The lack of any 'when' or 'when not' makes this weak.

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

• create_text_frameB
  3.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 discloses the primary behavior (creating a new text frame) and implies it adds a frame rather than modifying existing ones. However, it omits details such as whether the frame is placed on a specific page, error conditions (e.g., invalid page number), or any side effects. The essential behavior is clear 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, concise sentence with no filler. It states the core purpose efficiently and is appropriately front-loaded. Every word 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 the tool's moderate complexity (3 parameters, 1 required) and lack of annotations or output schema, the description is too sparse. It fails to explain when this tool should be used relative to siblings like set_frame_text or insert_text, what happens if the page doesn't exist, or what the return value is. An agent would need additional context to call it correctly in a broader task.

  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 provides 100% parameter descriptions, so the baseline is 3. The description mentions 'specified dimensions' which maps to geometricBounds, but it adds no extra meaning beyond the schema. It does not explain the 'page' or 'text' parameters, but the schema already covers them. Overall, minimal added value.

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

  Purpose4/5

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

  The description clearly states the action: 'Creates a new text frame on a page with the specified dimensions.' It identifies the verb (creates), the resource (text frame), and a key attribute (dimensions). However, it does not explicitly differentiate it from sibling tools like set_frame_text or insert_text, so it lacks explicit sibling distinction.

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

  Usage Guidelines2/5

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

  No guidance is provided on when to use this tool versus alternatives. It does not mention prerequisites, typical scenarios, or exclusions (e.g., 'use this when you need a new empty frame, not for editing existing text'). The agent must infer usage from the action alone, which is insufficient for routing across many similar siblings.

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

• export_pdfB
  3.2/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 disclosing side effects, but it only states the operation. It does not mention that PDF files will be written to outputDir, how overwrite behaves by default, how files are named, or what happens when no documents are open. For an export tool that creates files, this is a meaningful 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, front-loaded sentence with no filler. Every word contributes to stating the core action and scope, making it highly concise and easy to parse.

  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 tool with five parameters, no annotations, and no output schema, the description leaves too much unexplained: the relationship between outputDir and pageRange, the meaning of pdfPreset, overwrite behavior, and how multi-document export is structured. The schema documents parameter names, but not the operational behavior an agent needs to invoke the tool confidently.

  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 schema already documents all five parameters. The description's 'one or all' phrasing loosely reflects the document parameter but adds no new semantic value beyond what the schema already provides. This is the baseline for a fully covered 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, 'Exports', with a clear resource ('one or all open documents') and output format (PDF). It distinguishes this tool from export_image and quick_export, and the scope is immediately useful rather than a restatement of the tool name.

  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?

  There is no guidance about when to use export_pdf versus sibling tools like batch_export, quick_export, or export_image. The phrase 'one or all open documents' implies some batch capability, but the description never states when this tool is the right choice or when another tool should be preferred.

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

• insert_textB
  3.2/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 disclosing behavior. It only states a generic 'inserts text' without explaining default behavior (e.g., whether it replaces existing content by default, as the append parameter suggests), how frameIndex selects a frame, or error conditions. This is inadequate for a mutation tool with multiple parameters.

  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 with no filler words. It effectively communicates the core action in the fewest possible words, which is ideal.

  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 the tool has 4 parameters, no output schema, and no annotations, the description should provide more context. It omits key details such as the default frame index, how insertion position works, and what happens if the frame does not exist. The description is too sparse to guide correct invocation in complex scenarios.

  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 covers 100% of parameters with descriptions, so the baseline is 3. The description itself adds no additional meaning beyond the schema, and it does not clarify the semantic difference between 'insert' and 'replace' or how the append parameter modifies behavior, which could be considered a gap but is compensated by the schema's explicit parameter descriptions.

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

  Purpose5/5

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

  The description uses a specific verb 'inserts' and identifies the resource 'text frame' within the 'active document'. This clearly distinguishes it from siblings like set_frame_text (which likely replaces entire text) and replace_text (which targets specific content). The purpose is 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 explain when to use this tool versus alternatives such as set_frame_text or replace_text. It lacks any explicit context about selection of the frame or position of insertion, so an agent has no guidance on selecting it over sibling tools.

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

• list_colorsA
  3.5/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 disclose behavioral traits. It says 'Lists' implying a read operation, but it does not confirm the operation is non-destructive or explain the default behavior that filters to only colors unless 'all' is requested. The phrase 'colors and tints' could mislead an agent into thinking all types are always returned, which is not the case given the schema default.

  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 with no filler. It front-loads the action and resource, and every word contributes to the meaning.

  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, the description covers the basic purpose but leaves out the behavior of the optional parameter and the exact format of the returned list. Since there is no output schema and no annotations, the description could have explained default filtering and response shape, so completeness is adequate but not thorough.

  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, swatchType, is fully described in the schema). The description adds no additional meaning or usage guidance for the parameter, so it stays at the baseline for high 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?

  The description clearly states the action (Lists) and the resource (all colors and tints in the active document). It is specific enough to distinguish from sibling tools like list_styles and list_frames, and the active-document scope adds precision.

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

  Usage Guidelines3/5

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

  The description implies the tool is for retrieving swatches but does not explicitly mention alternatives or exclusions. An agent would need to infer when to use this versus list_styles, so guidance is only implied, not stated.

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

• batch_exportA
  3.6/5.0
  Behavior2/5

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

  With no annotations provided, the description carries full burden for behavioral disclosure. It mentions running a script, but does not disclose side effects such as file writes, overwrite behavior, potential performance impact, prerequisites (like a running Photoshop session), or whether the operation is destructive. This is a significant gap for a mutation tool.

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

  Conciseness5/5

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

  The description is two concise sentences, front-loaded with the primary action and then a usage hint. Every word contributes; there is no fluff or repetition. It is appropriately brief for a tool whose parameters are fully documented in the schema.

  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?

  Despite having 11 parameters, the description provides only a high-level overview. It lacks any mention of expected output (e.g., success message, log file), prerequisites (like Photoshop being open), or side effects (file system changes). Although the schema covers parameters, the description should provide more context for a tool with no output schema and no annotations, leaving critical execution details to the agent's inference.

  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 all 11 parameters have descriptions in the schema. The tool description does not add any additional parameter-level semantics beyond the high-level 'multiple formats' note, which matches the 'formats' parameter. Per the baseline, a score of 3 is appropriate when the schema fully documents parameters and the description adds minimal extra 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 verb ('Runs'), the resource ('batch export'), the method ('using the existing BatchExportProfessional.jsx script'), and the scope ('exporting multiple formats at once'). This distinguishes it from sibling tools like export_pdf or export_image, which target single formats.

  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 'Ideal for exporting multiple formats at once' provides a clear context for when to use this tool. However, it does not explicitly state when not to use it or name alternative tools (e.g., use export_pdf for a single PDF), leaving some ambiguity for an agent deciding between batch and single exports.

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

• list_stylesA
  3.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 burden. It clearly indicates a read-only listing operation on the active document, which is the key behavioral trait. However, it does not mention whether only one style type is returned at a time or whether the output is limited by the default styleType.

  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 front-loads the core action and resource, making it easy to scan.

  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 tool, the description plus input schema is mostly sufficient. It lacks an explicit note about the default styleType behavior and what the returned list contains, but the schema fills the main gap and the tool is low complexity.

  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 parameter is already fully documented via the enum and the 'Style type' description. The description mentions paragraph and character styles, which partially mirrors the enum, but it adds no meaningful semantics beyond the schema.

  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 the specific verb 'Lists' and names the resource: paragraph, character, and other styles in the active document. It is clear enough to distinguish from action-oriented siblings like apply_style or list_colors, but it does not explicitly differentiate itself from any sibling.

  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 apply_style or list_colors. The intended context is only implied by the verb 'Lists' and the resource name, not explicitly stated.

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

• create_color_swatchA
  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 full behavioral disclosure burden. It does communicate that this is a mutating operation that adds a new item to the active document. However, it does not address duplicate names, invalid color values, whether the document must be open, or what happens on failure.

  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, direct sentence with no filler. The core action and scope are front-loaded, making it easy for an agent to parse quickly.

  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 low-complexity create operation, the description plus a fully documented schema is mostly sufficient. It lacks explicit usage alternatives and some behavioral edge-case details, but no critical information is missing for the basic success path.

  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 provides 100% description coverage for all four parameters, including enums and defaults. The description adds no additional parameter semantics, so the baseline of 3 applies.

  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 ('Creates'), a concrete resource ('a new color swatch'), and the scope ('in the active document'). This clearly distinguishes it from sibling tools like list_colors, which only reads swatches, and create_text_frame, which creates a different object.

  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 intended use is implied by the description: use this when a new color swatch should be added to the active document. However, it does not explicitly state when not to use it or mention alternatives, leaving some routing decisions to inference.

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

• list_documentsA
  3.9/5.0
  Behavior2/5

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

  With no annotations, the description carries the full burden of behavioral disclosure. It only states that it lists open documents but does not mention return format (e.g., names, IDs, paths), ordering, or any side effects. This is minimal and leaves the agent guessing about the response structure.

  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 with no filler. It front-loads the action and scope, and every word 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?

  For a tool with no parameters and no output schema, the description is adequate but not complete. It does not specify what information the list will contain (names, IDs, etc.), which could be important for an agent to decide if it should use a different tool like get_document_info. Since the siblings vary widely, a bit more detail on the return format would improve completeness.

  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 coverage is technically 100% (vacuously). Per the rubric, a tool with 0 parameters receives a baseline score of 4. The description adds no parameter info, but that is not needed here.

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

  Purpose5/5

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

  The description states a clear verb ('Lists') and a specific resource ('all InDesign documents currently open'). It distinguishes this from sibling tools like get_document_info (which targets a specific document) and export tools, making the purpose immediately obvious.

  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 'currently open' provides clear context for when to use this tool. However, it does not explicitly mention when not to use it or name alternative tools such as get_document_info for specifics. For a simple list operation, the usage is well implied, so a 4 is appropriate.

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

• run_jsxA
  4/5.0
  Behavior3/5

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

  With no annotations, the description must disclose behavioral traits. It warns 'run trusted code only,' which hints at risk, but it does not explain that executing code can arbitrarily modify or destroy the document, nor does it clarify the nature of the result. The warning is some insight, but the full behavioral profile 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 clauses with no filler. The purpose and usage are front-loaded, making it efficient and immediately scannable. Every part 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?

  The tool is complex (general code execution), yet the description omits any mention of return values, error behavior, or side effects. With no output schema or annotations, the agent has no idea what to expect after execution, making the description incomplete 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 coverage is 100% with both code and waitForResult described, so the description adds no additional parameter semantics. It merely restates that code is arbitrary, which is already in the schema. The baseline of 3 applies since the schema handles all parameter 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 it runs arbitrary ExtendScript code in InDesign, a specific verb and resource. It also differentiates from siblings by noting it is for custom automation not covered by other tools, making its 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 Guidelines5/5

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

  It explicitly says 'Use for custom automation not covered by other tools,' which provides clear when-to-use guidance and implies using specific sibling tools when applicable. This is a direct usage directive with implicit alternatives.

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

• check_connectionA
  4.2/5.0
  Behavior3/5

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

  With no annotations and no output schema, the description carries the full burden. It accurately states the check's purpose but does not disclose what the tool returns (e.g., a boolean result, a success message, or an error when InDesign is closed), nor how it signals failure. The core behavior is clear, but edge-case response semantics are left unspecified—acceptable for a simple preflight, yet a tangible 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?

  Two sentences with zero waste. The first delivers the purpose, the second delivers the usage imperative. The key precondition is front-loaded and prominently stated. Nothing extraneous.

  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 health-check tool, the description is essentially complete: it names the target application, states the condition it verifies, and explains when to run it. The only omission—the exact return value format—is minor for a preflight check whose result an agent primarily uses as a go/no-go signal.

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

  Parameters4/5

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

  The tool has zero parameters, and with no properties in the schema there is nothing to document. The 0-param baseline of 4 applies here; the description correctly omits parameter details because none exist. No information is missing on this dimension.

  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 ('Checks') and resource ('whether Adobe InDesign is open and responding'). It naturally distinguishes itself from all sibling tools, which are document/export/text operations—none of them perform connectivity checks. An agent can instantly identify this as the health-check preflight 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 instruction 'Run this tool before using the others' gives explicit, actionable context on when to invoke it—as a prerequisite for every other operation. It does not spell out when not to use it or name alternatives, but as the lone connection-check tool among siblings, no alternative is needed. The guidance is clear and sufficient.

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