Server Quality Checklist

Tool Scores

• run-commandB
  3.2/5.0
  Behavior3/5

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

  The description discloses that it returns either a correlated result or a durable request ID, implying both synchronous and asynchronous behavior. However, it does not mention side effects, permissions, or whether commands may mutate state. With no annotations, it carries the burden and only partially addresses it.

  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-loading the core purpose and then adding a relevant detail about parameter naming and return types. No unnecessary words or repetition.

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

  Completeness4/5

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

  Given the tool's generic nature spanning 19 commands, the description provides a reasonable high-level overview. It addresses the return type and gives a parameter naming hint. Without an output schema, it could be more explicit about the structure of the result, but the current level is adequate for initial context.

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

  Parameters2/5

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

  Schema coverage is 0% and the generic parameters object provides no per-command details. The description adds a single example (createNullObject uses compId) and notes upstream parameter naming, but fails to explain meaningful parameter usage for the remaining 18 commands. The compensation is minimal.

  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 it runs a predefined AE command, establishing the verb and resource. It distinguishes from siblings by focusing on predefined commands rather than arbitrary execution, though it could list or reference the command set more explicitly.

  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 execute-jsx or other sibling tools. The mention of upstream parameter names is about semantics, not usage context. There is no 'when to use' or 'when not to use' information.

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

• get-renderB
  3.3/5.0
  Behavior3/5

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

  Annotations are absent, so the description carries the full burden. It discloses that job IDs are valid for the server lifetime and logs survive restarts, which is useful operational context. However, it does not state whether the operation is read-only, whether it has side effects, or what the response contains. The disclosed behavior is minimal but not misleading.

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

  Conciseness5/5

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

  The description is two sentences with zero redundancy. The primary purpose is front-loaded, and the additional caveat about job ID validity is placed second, preserving clarity. 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 simple one-parameter status tool, the description covers the core purpose and a relevant operational detail. However, it omits what the response looks like (since no output schema exists), which an agent might need to interpret results. It is minimally complete but not fully self-sufficient.

  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?

  With 0% schema description coverage, the description must compensate for the single 'id' parameter. It implies that 'id' refers to a job ID by stating 'Job IDs are valid...', which gives some meaning. However, it does not explain the format, source, or how to obtain the ID, leaving the agent with partial understanding. The compensation is adequate but not thorough.

  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 (get) and the resource (aerender job status), which is specific enough to distinguish from generic tools like get-request or bridge-status. However, it does not explicitly differentiate from sibling tools, so it lacks the extra clarity of naming an alternative.

  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 on when to use this tool versus alternatives. The description mentions job ID validity and log persistence, but provides no context about selection criteria or exclusions. The agent is left to infer when this tool is appropriate.

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

• import-footageB
  3.3/5.0
  Behavior2/5

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

  No annotations provided, so the description must carry full behavioral disclosure. It explains the primary action and optional composition addition, but does not mention side effects, permissions, failure modes, or reversibility.

  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, concise sentence that efficiently communicates the core functionality. No unnecessary words or redundant details.

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

  Completeness3/5

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

  The tool is simple, but the description omits any mention of return value or success/failure indicators. It also does not clarify whether the imported footage can be referenced later via an ID, which is relevant for follow-up operations.

  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 some meaning to parameters: 'path' is described as a local file or image sequence, and 'compId' relates to a composition. However, it does not fully explain the role of 'sequence' (e.g., how it modifies path interpretation) or the exact effect of compId.

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

  Purpose5/5

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

  Clearly states the verb 'import' and the resource 'local file or image sequence'. Also mentions the optional action of adding to a composition, which makes it distinct from sibling tools like render-composition or execute-jsx.

  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 alternatives. Lacks any mention of scenarios where import-footage is appropriate or not, nor does it reference sibling tools.

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

• render-compositionB
  3.3/5.0
  Behavior4/5

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

  Without annotations, the description carries the full burden. It discloses important side effects: 'AE is busy until rendering finishes' and the necessity of polling after a pending response. This is good but could go further (e.g., how the return looks, error conditions).

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

  Conciseness5/5

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

  The description is two sentences, directly states the core purpose, and front-loads the key action. No fluff or redundant detail; it is concise and well-organized.

  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?

  While the description mentions the asynchronous behavior and the need to poll, it omits essential context such as parameter meanings, expected outcomes, or how to handle failure. Given the lack of output schema and parameter descriptions, this is insufficient for a confident invocation.

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

  Parameters1/5

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

  The input schema has zero parameter descriptions, and the description does not explain any of the five parameters (compId, overwrite, outputPath, outputTemplate, renderTemplate). The description fails to compensate for the lack of schema coverage, leaving the agent guessing about parameter meanings.

  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 ('Render a composition'), the target ('in the running AE application'), and a specific behavior ('preserving other queue selections'). This distinguishes it from sibling tools like render-project, which likely targets the whole project.

  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 a post-call instruction ('Poll get-request after a pending response') but does not explicitly state when to use this tool versus alternatives like render-project or get-render. No when-to-use or when-not-to-use guidance is given.

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

• render-projectA
  3.7/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 discloses that logs are saved locally, that the operation is asynchronous (poll get-render), and that the AE version must match the project. It doesn't cover error handling or return details, but for a render-start command it conveys the key side effects.

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

  Conciseness5/5

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

  Three concise sentences, with the core action and key constraints front-loaded. No wasted words.

  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 7-parameter tool with no annotations and no output schema, the description is far from complete. It omits explanations for most parameters, return behavior, and failure modes. The useful bits (no bridge, logs, polling) are not enough to make this tool safely callable.

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

  Parameters1/5

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

  Schema coverage is 0%, so the description must explain parameters. It only references 'saved .aep project' (projectPath) but says nothing about composition, outputPath, or the other 4 parameters. This leaves the agent guessing at what values are expected.

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

  Purpose5/5

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

  The description clearly states the tool starts aerender for a saved .aep project, explicitly distinguishing it from a bridge-based render (without an open bridge). It also names the polling tool (get-render) and a version prerequisite, 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 Guidelines4/5

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

  It gives a clear condition for use ('without an open bridge') and directs the agent to poll get-render afterward. It does not explicitly name alternatives like render-composition when a bridge is open, but the implied headless workflow is reasonably clear.

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

• execute-jsxA
  3.8/5.0
  Behavior3/5

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

  No annotations provided, so description carries full burden. Discloses that it may modify projects and files, which is critical. Recommends ES3 for AE 2024+, but does not mention error behavior, timeouts, or the execution environment, leaving some uncertainty for a potentially dangerous operation.

  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?

  Three sentences, each providing distinct value: purpose, code format, and side-effect warning with syntax note. Efficient and well-structured, though could be slightly more detailed without much added length.

  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?

  Provides essential information for executing code: purpose, code format, and side effects. However, lacks details on error handling, whether AE must be running, or any constraints, which is significant for a tool that runs arbitrary code. Output schema absent, but return guidance helps. Overall, adequate but with gaps.

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

  Parameters4/5

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

  With 0% schema coverage, description adds meaning to the code parameter by specifying it's a function body and how to return a result, and explains the parameters object is accessible as args. This compensates for the lack of schema descriptions, though it could give more detail on parameter structure.

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

  Purpose5/5

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

  Clearly states it executes arbitrary ExtendScript in AE, specifying verb, resource, and context. Distinguishes from siblings like run-command by emphasizing the arbitrary script execution in AE.

  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?

  Provides clear context on how to format the code (function body, return value, parameter access) but does not explicitly state when to use this tool over alternatives like run-command, nor when not to use it. Lacks tool-selection guidance.

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

• get-requestA
  3.8/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 transparency burden. It discloses important non-obvious behavior: pending/running is a valid state, not an error, and automatic resubmission of interrupted mutations is forbidden. This is meaningful beyond the schema, though details like return format or error behavior are not covered.

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

  Conciseness5/5

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

  The description is two short sentences with no filler. The primary action is front-loaded, and the critical behavioral warning follows immediately, making every word earn 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 simple one-parameter read operation, the description covers the essential purpose and the most important edge-case behavior. The lack of an output schema means some return-value detail is missing, but the description is adequate for correct 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?

  The schema has a single required 'id' string with 0% description coverage, so the description must compensate. It only restates 'by ID' without explaining the ID's format, origin, or semantics, leaving the agent to infer what value to supply.

  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 operation ('Read one request by ID') with a specific verb and resource, making the core purpose unambiguous. It does not explicitly differentiate from sibling tools like get-render or bridge-status, but the 'request' resource is distinct enough for an agent to select it.

  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 behavioral context: pending/running status should not be treated as failure, and interrupted mutations must never be automatically resubmitted. This effectively guides post-invocation handling, though it does not explicitly compare against alternative tools.

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

• launch-bridgeA
  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 behavioral disclosure burden. It explains that no Startup script is installed and no panel remains open, and it warns about the one-instance concurrency limit. It does not cover what happens if a bridge is already running, but it gives meaningful operational context beyond the bare action.

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

  Conciseness5/5

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

  Three short sentences, each adding distinct information: the action, the exclusions, and the prerequisite/constraint. There is no redundant or filler content, and the key scope is front-loaded.

  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 description covers the launch action, prerequisites, and concurrency constraint, which is solid for a small tool. However, it leaves the year parameter's role and the 'selected' version mechanism ambiguous, and it does not suggest how to verify a successful launch, such as using bridge-status. These gaps matter for an agent deciding whether to omit or set year.

  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 0%, and the only parameter, year, is left unexplained. The phrase 'selected installed AE version' is the only indirect hint that year selects the version, but it does not explicitly connect year to the parameter. The optional nature of year and the fallback selection behavior are also unclear.

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

  Purpose5/5

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

  The description opens with a specific action, 'Launch the background bridge,' and names the target context, 'selected installed AE version.' It also distinguishes itself from alternatives by explicitly stating what it does not do: 'without installing a Startup script or keeping a panel open,' which separates it from tools like execute-jsx or run-command.

  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 prerequisites and constraints: 'Enable scripting file access in AE first' and 'Only launch in one AE instance at a time.' It implies when to use this tool, but it does not explicitly name alternative tools or state when not to use it.

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

• save-projectA
  4/5.0
  Behavior3/5

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

  With no annotations, the description carries full burden. It adds useful context: it targets the 'current' project and requires an 'absolute' path. However, it does not disclose that saving overwrites an existing file, whether the operation is reversible, or what happens on failure (e.g., invalid path, no open project). These are meaningful behavioral gaps 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 a single, well-constructed sentence with zero filler. The action and the critical path constraint are both front-loaded, making it easy to scan and immediately actionable.

  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 covers the essential information: what is saved, the target, and the path format. It does not mention return values or error behavior, but given the simplicity and the absence of a sibling for saving, it is largely sufficient for an agent to invoke 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?

  Schema coverage is 0%, so the description must compensate. It does by specifying that the path must be 'absolute' and have the '.aep' extension, directly enriching the meaning of the single 'path' parameter. This goes beyond the bare schema and gives the agent the key constraints needed to call it correctly.

  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 ('Save') on a specific resource ('current AE project') with a specific destination ('absolute .aep path'). This is unambiguous and clearly distinct from all sibling tools, none of which involve saving projects.

  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 purpose is so self-evident that usage is implied, but the description gives no explicit when-to-use conditions or alternatives. It does not mention prerequisites like an open project, or contrast with any other save-like action, so it relies on the agent inferring the obvious use case.

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

• list-installationsA
  4.1/5.0
  Behavior4/5

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

  The verb 'Discover' suggests a read-only operation with no side effects. There are no annotations to contradict this, and the description does not mention any modifications or destructive actions. A slightly higher score would require an explicit statement of non-mutating behavior.

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

  Conciseness5/5

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

  The description is a single, concise sentence that captures the essence without fluff. It is front-loaded with the main action and result, making it easy to parse quickly.

  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 description does not specify the return format or structure (e.g., a list of objects with version and path fields). Since there is no output schema, this missing detail could lead to ambiguity. However, for a simple discovery tool, the lack of return details is partially compensated by the clarity of the purpose.

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

  Parameters4/5

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

  The tool has zero parameters, so the baseline score of 4 applies. There is no parameter documentation needed, and the description does not imply any hidden inputs.

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

  Purpose5/5

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

  The description clearly states the tool's function: discovering installed After Effects 2024+ versions and aerender paths. It uses a specific verb ('Discover') and names the resource, distinguishing it from other tools like get-request or render-composition.

  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 it (when needing to know installed versions/paths) but does not explicitly contrast it with alternatives or state conditions for selection. The purpose is obvious, but explicit guidance is absent.

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

• bridge-statusA
  4.4/5.0
  Behavior4/5

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

  No annotations are provided, so the description must convey behavior. The verb 'Check' implies a read-only operation with no side effects. Explicitly stating 'no visible panel is necessary' clarifies it does not alter UI state. Could be more explicit about not modifying anything, but it's reasonably transparent.

  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?

  Extremely concise, two sentences. No filler or redundant information. Front-loaded with the primary purpose.

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

  Completeness4/5

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

  Given the simplicity of the tool (no parameters, simple status check), the description is complete. It explains the required condition (AE running) and a key detail (no panel needed). Omission of return format is acceptable since no output schema is provided and the purpose is obvious.

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

  Parameters4/5

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

  No parameters exist, so this dimension is not applicable. Baseline of 4 is appropriate; description adds no parameter-specific information because none exist.

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

  Purpose5/5

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

  Clearly states the tool's function: checking the connected AE application and runtime version. No ambiguity.

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

  Usage Guidelines4/5

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

  Provides important usage context: requires AE running and notes that no visible panel is needed. Could mention when to use it (e.g., before other AE operations) but is sufficient.

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