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

Annotations only say the operation is not read-only and not destructive, so the description carries the behavioral burden. It usefully discloses the return value ('md5 asset name usable in projects') and the SVG/dimension constraints, while avoiding any contradiction with the annotations.

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

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

Three short sentences that front-load the purpose and put the most important constraints and return behavior right after. No filler or repetition of schema details.

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

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

There is no output schema and no parameter descriptions, yet the tool still communicates key requirements and the return shape. It is minimally viable, but gaps remain around the name parameter and how width/height should be determined for characters versus the 480×360 background convention.

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

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

Schema description coverage is 0%, and the description helps with svg (matching viewBox), kind (character/background), and width/height (background 480×360). However, the required 'name' parameter is never explained and character width/height semantics are left implicit, so compensation is only partial.

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

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

States a specific verb ('Add') and a concrete resource ('custom character or background') with a qualifier ('static SVG geometry'). This cleanly separates it from sibling project-management tools and list_assets, so an agent can tell what the tool does at a glance.

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

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

Gives direct usage context: it is the tool for adding SVG-based custom characters/backgrounds, and it imposes concrete format rules ('SVG with a matching viewBox; backgrounds should be 480×360'). It does not explicitly name alternatives or exclusions, but no sibling offers the same add-asset action.

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

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

Annotations only indicate non-read-only, non-destructive behavior. The description adds useful context by stating that it saves current work and creates a full timestamped database backup, implying persistence and uniqueness. It does not detail backup location or completion behavior, but for a zero-parameter tool this is 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.

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

A single, compact sentence conveys the full action without filler. Both clauses—'save current work' and 'make a full timestamped database backup'—contribute meaningful information.

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

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

For a zero-parameter action with no output schema, the description fully covers what the tool does and the scope of its effect. No additional context is needed for an agent to invoke it correctly.

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

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

The tool has zero parameters, so the schema provides full coverage by definition. The baseline of 4 applies because there are no parameter semantics to explain.

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

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

The description uses concrete verbs ('Save', 'make') and a specific resource ('full timestamped database backup'). It is clearly distinct from siblings like scratchjr_save_project or scratchjr_export_project by emphasizing a full database backup rather than a single project.

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

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 instead of alternatives such as scratchjr_save_project or scratchjr_export_project. It does not mention preconditions, recommended timing, or situations where a backup is necessary.

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

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

Annotations already establish readOnlyHint=true and destructiveHint=false, and the description's 'Get' wording is consistent. The description adds that the tool returns a catalog of blocks, values, units, and guidance, but it does not disclose output format, structure, or any other behavioral traits. Given the annotations cover safety, this is adequate but not rich.

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

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

The description is a single, front-loaded sentence that lists the key resources without excessive wording. The phrase 'project-building guidance' is slightly vague but does not add bloat or hinder quick parsing.

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

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

For a zero-parameter, read-only reference tool, this description is largely complete: it identifies the kind of information returned and is consistent with annotations. The main gap is the vagueness of 'guidance,' but an AI agent can still understand the tool's purpose and safe invocation without additional detail.

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

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

The input schema has zero properties, so there are no parameters requiring semantic explanation. The description does not need to compensate for schema gaps, and the baseline for a no-parameter tool is appropriately high.

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

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

The description uses a specific verb ('Get') and names concrete resources: 'supported blocks, values, units and ScratchJr project-building guidance.' This distinguishes it from action-oriented siblings like create_project, run_project, or backup, though it does not explicitly call out a sibling comparison.

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

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 such as scratchjr_status, scratchjr_list_assets, or scratchjr_get_project. An agent must infer that this is a reference/lookup tool from the description, but no explicit context or exclusions are given.

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

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

Annotations already indicate this is not read-only and not destructive, and the description adds a useful precondition about the character being on the current page. It does not disclose potential side effects of the click event, such as triggering project scripts that modify state, but for a simple event trigger this is a reasonable level of transparency.

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

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

Two short sentences convey the action, purpose, and a critical prerequisite without any filler. The most important information appears first, and every word earns its place.

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

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

For a single-parameter tool, the description covers the core action and the main precondition. It omits expected return behavior, error handling when the character is not on the page, and how to identify the objectId, so it is adequate but not fully self-sufficient.

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

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

Schema description coverage is 0%, and the description does not explain what objectId refers to or how to obtain it. The parameter name and tool name make it inferable that objectId identifies the character, but the description adds no meaning beyond the raw schema.

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

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

The description states a specific action ('Trigger a character click event') and a concrete resource ('character'), making the tool's function immediately obvious. It also clarifies the intended use case ('to test an interactive project'), and the sibling list contains no other click/event tool, so it is effectively distinguished.

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

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

The description implies when to use the tool ('to test an interactive project') and gives a key precondition ('Character must be on the current page'). However, it offers no explicit comparison to alternatives or exclusions, leaving the agent to infer the usage context from the sibling names.

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

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

Annotations provide only basic hints, so the description adds useful behavioral context: it does not force-close existing sessions and uses a localhost-only port. This is meaningful beyond the structured annotations and there is no contradiction.

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

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

Two short sentences with no redundancy. The core connection/launch behavior is front-loaded and the important safety clarification follows immediately.

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

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

For a simple setup tool with no parameters or output schema, the description covers the essential behavior and key caveat. It could explicitly mention whether this must be called before other ScratchJr tools, but the sibling set and the non-closing statement make that reasonably inferable.

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

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

The tool has zero parameters and schema description coverage is 100%, so there is nothing for the description to add. Baseline 4 is appropriate for a parameterless tool.

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

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

States a clear action ('Connect to ScratchJr Desktop or launch it') with a specific resource and a scope qualifier ('localhost-only control port'). It also clarifies what it does not do, distinguishing it from other tools like scratchjr_status.

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

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

The description implies when the tool is useful (when a connection is needed, possibly launching Desktop) and includes a safety note about existing sessions, but it does not explicitly state when to prefer it over siblings or any prerequisites/ordering. Usage is implied rather than fully guided.

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

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

The description goes beyond the readOnly=false/destructive=false annotations by disclosing that the project is persisted and opened, not just created in memory, and that construction of characters/backgrounds/text/scripts is automatic. It also states the return value (new ID and data), though it omits failure conditions or prerequisites like connectivity.

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

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

Two sentences front-load the action, resource, constraint, and return value. Every clause adds information, and there is no filler, repetition of schema structure, or redundant restating of annotations.

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

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

For a complex tool with a deeply nested schema and no output schema, the description supplies the missing high-level context: single-call creation, persistence, opening, automatic assembly, the four-page cap, and the returned ID/data. It omits explicit prerequisites such as connecting first or ensuring asset IDs exist, though the schema's asset description already points to scratchjr_list_assets.

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

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

With 0% schema_description_coverage, the description carries some burden, and it helps by framing `project` as high-level content that the tool assembles into a native project with up to four pages. It does not walk through required fields or nested block semantics, but the schema itself is unusually detailed with defaults, enums, and constraints, so most operational meaning is available there.

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

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

The description names a specific action (create/persist/open), a clear resource (a complete native ScratchJr project), and key constraints ('up to four pages', auto-built characters/backgrounds/text/scripts). This makes it distinguishable from siblings like scratchjr_edit_project or scratchjr_list_projects, though it never explicitly names them.

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

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

The verb 'Create' and 'Returns the new ID' imply this should be used when building a new project rather than editing or opening an existing one. However, the description gives no explicit when-not-to-use guidance or alternatives, leaving the agent to infer the boundary against scratchjr_edit_project, scratchjr_save_project, and scratchjr_open_project.

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

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

Annotations already declare readOnlyHint=false and destructiveHint=false, so the description doesn't need to restate mutation. The description adds useful behavioral context: the tool reopens the project after editing, and set_character replaces the whole character. However, it doesn't disclose that edits are batched atomically, whether a failed operation rolls back, or that expectedRevision is an optimistic concurrency guard. With annotations covering the basic safety profile, a 3 is appropriate.

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

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

Three sentences with no filler. The key action ('Apply a batch of edits') is front-loaded, the revision requirement is stated early, and the set_character/set_scripts distinction is a valuable disambiguation. It could be slightly more structured by listing operation types, but it earns its place.

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

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

For a complex tool with a large operations schema and no output schema, the description is adequate but not complete. It covers the core workflow (get revision, batch edit, reopen) and the most important sibling distinction, but it doesn't mention the available operation actions, the optimistic concurrency semantics of expectedRevision, or what happens on failure. An agent would need to dig into the schema to understand the full operation set, which is a gap for a tool this complex.

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

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

Schema description coverage is only 33% (projectId and asset have descriptions, but expectedRevision and operations do not). The description compensates partially by explaining expectedRevision ('Supply the revision from get_project') and by clarifying the set_character vs set_scripts distinction. However, it doesn't explain the structure of operations (the oneOf variants) or that operations is a batch array, leaving the agent to parse the large schema. Baseline 3 is fair because the description adds some meaning but doesn't fully compensate for the coverage gap.

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

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

The description states a specific verb ('Apply a batch of edits') and resource ('existing project'), and clarifies it reopens the project. It also distinguishes set_character from set_scripts. However, it doesn't enumerate the full set of operations (rename, add_page, set_background, add_character, add_text, set_text, remove_object) that the schema supports, so an agent might not realize the full scope of what 'batch of edits' includes.

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

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

The description gives clear context: use this to apply edits to an existing project, supply the revision from get_project, and use set_scripts instead of set_character when changing only code. It doesn't explicitly state when NOT to use this tool (e.g., for creating a new project, use create_project), but the sibling list and the 'existing project' phrasing imply that boundary.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds value beyond annotations by disclosing the output format (JSON backup) and that referenced custom media is included, which is behaviorally relevant.

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

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

Two short sentences with no filler. The core action and output are front-loaded, and the format clarification earns its place by preventing confusion with the .sjr format.

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

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

For a simple single-parameter read-only export tool, the description is complete: it states the output format, scope, and key constraint. The schema documents the only required parameter, and annotations cover safety, so nothing critical is missing.

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

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

Schema description coverage is 100%, and the projectId parameter is already well documented as coming from list_projects or create_project. The tool description itself adds no additional meaning about the parameter, so the baseline score of 3 applies.

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

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

The description uses a specific verb ('Export') and identifies the exact output: 'a JSON backup of a project and referenced custom media.' It also distinguishes itself from the tablet .sjr sharing format, which helps differentiate it from sibling backup/export tools.

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

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

The description makes it clear when this tool is appropriate: when a JSON backup including custom media is needed. The explicit 'not the tablet .sjr sharing format' provides a useful exclusion, though it does not name a specific alternative sibling to use instead.

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

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

Annotations already provide readOnlyHint=true and destructiveHint=false. The description adds genuine value beyond those annotations by disclosing that the read includes unsaved editor state when open — a behavioral trait the agent needs to know. No contradiction with annotations.

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

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

Three short sentences, each earning its place: purpose and scope first, then the unsaved-state nuance, then the usage trigger. No redundancy, no filler.

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

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

For a single-parameter read tool with safety annotations in place and no output schema, the description compensates by naming the returned content (project data, page/object IDs, revision). Minor ambiguity remains around what 'when open' means, but the tool is simple enough that this is adequate.

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

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

Schema coverage is 100%; projectId is fully documented ('Project ID from list_projects or create_project'). The description adds no parameter-level detail, but with full schema coverage the baseline of 3 applies and nothing more is demanded.

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

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

The description states a specific verb ('Read') and resource ('project data, page/object IDs and revision'), with the distinct behavioral note about unsaved editor state. It's clearly differentiable from siblings like list_projects or edit_project by content, though it never names a sibling explicitly.

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

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

'Call before editing' provides a clear trigger condition for when this tool should be invoked. It gives solid context but stops short of explicit when-not-to-use guidance or naming alternatives such as edit_project/save_project.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the agent knows this is safe. The description adds the qualifier 'real installed' to differentiate from hypothetical or virtual assets, but it does not disclose output structure, pagination, or any other behavioral nuance. With annotations covering safety, the bar is lower, yet the description adds only minimal extra context.

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

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

Two crisp sentences. The first states the core purpose; the second provides a key usage hint. No filler or repetition. The information is front-loaded and every word earns its place.

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

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

The tool is simple with two optional parameters and no output schema. The description tells what it lists and hints that md5 filenames are returned, but it does not explicitly describe the return format or explain the 'search' parameter. For a low-complexity tool this is adequate but not fully complete; the agent still has to infer some behavior from the parameter names.

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

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

Schema description coverage is 0%, meaning the description does not explain either parameter. The schema itself provides enum values for 'kind' and a maxLength for 'search', but the description does not clarify what 'search' does or how 'kind' interacts with the listing. Since coverage is low, the description must compensate, and it fails to do so.

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

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

The description clearly states the tool lists installed assets (characters, backgrounds, sounds). It distinguishes from siblings like scratchjr_add_svg_asset by focusing on listing rather than adding. The purpose is unambiguous and specific.

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

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

The description provides a practical usage hint: 'Use exact md5 filenames in projects.' This tells the agent why to call the tool (to get md5 filenames for project references). It does not explicitly contrast with alternatives, but for a listing tool the use case is straightforward and no conflicting sibling exists.

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

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

The description aligns with the annotations: readOnlyHint is true and destructiveHint is false, and 'List' is non-mutating. It adds no extra behavioral detail beyond the annotation, such as return shape or side-effect confirmation, which is acceptable for a no-arg read-only operation but not enriching.

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

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

A single, front-loaded sentence states exactly what the tool does with no filler or redundancy. Every word earns its place.

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

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

The zero-parameter schema and read-only annotations cover invocation safety, and the description makes the purpose unambiguous. It does not describe the shape of the returned project list, which would improve completeness given the absence of an output schema.

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

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

There are no parameters, so there is no semantics for a description to clarify beyond the empty schema. The no-parameter baseline applies.

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

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

States the specific verb 'List' and resource 'saved ScratchJr projects', clearly orienting an agent to a read-only enumeration action. It does not explicitly contrast with scratchjr_list_assets or say whether all projects are returned.

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

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

No when-to-use or exclusion guidance is provided; an agent must infer when to choose this over scratchjr_list_assets or scratchjr_get_project. This leaves usage context to the tool name and sibling names.

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

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

The description discloses one meaningful behavioral side effect beyond the annotations: it saves the current project before opening another. However, it does not explain what happens on failure, whether unsaved changes are silently overwritten, or why 'real editor' matters. Since readOnlyHint is false, the safety profile is already known from annotations, and the description adds only modest context.

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

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

A single sentence that front-loads the key action (saving the current project) and states the main operation without filler. Every phrase carries useful information.

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

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

For a one-parameter tool with a documented schema this is minimally adequate, but it omits any mention of return value/behavior, connection prerequisites (despite scratchjr_connect existing), or what distinguishes opening in the real editor from other project operations.

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

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

The schema already documents projectId as 'Project ID from list_projects or create_project' with full coverage. The description adds no further parameter semantics beyond 'requested project,' so the baseline 3 is appropriate.

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

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

The description uses specific verbs and resources: 'Save the current project' and 'open the requested project in the real editor.' It clearly identifies the tool's function, but it does not explicitly contrast it with sibling tools like scratchjr_edit_project or scratchjr_get_project, so it stops short of full sibling differentiation.

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

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 such as scratchjr_edit_project, scratchjr_get_project, or scratchjr_run_project. The intended use is only implied by the name and description, with no exclusions, prerequisites, or conditions stated.

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

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

Annotations already establish that the tool is not read-only and not destructive. The description adds the useful detail that providing projectId triggers an open-then-run sequence. However, it does not disclose whether currently running scripts are stopped or whether execution is synchronous, leaving some behavioral ambiguity.

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

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

The description is a single front-loaded sentence that states the primary action first and then the parameter-dependent behavior. There is no filler, no repetition of the tool name, and every word earns its place.

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

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

For a tool with one optional parameter and annotations providing the safety profile, the description gives enough information for an agent to invoke it correctly. It covers the current-project vs specified-project distinction, though it does not explain what happens if no current project exists or whether the run blocks.

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

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

The schema describes projectId as a project ID, but the description adds the key meaning that it is optional and selects which project to open before running. With 100% schema description coverage, this is above the baseline of 3 because it clarifies the parameter's role in the overall operation.

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

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

The description names a specific action ('Run green-flag scripts') and a resource ('current project' or 'specified project'), which clearly distinguishes it from sibling tools like open_project and stop_project. It is a precise verb+resource statement, not a tautology.

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

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

The description clearly states the context: run in the current project, or open and run a specified project when projectId is provided. It does not explicitly name alternatives or state when not to use the tool, but the selection context is clear enough for an agent.

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

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

Adds behavioral detail beyond annotations by mentioning thumbnail regeneration and durability ('flush all data to disk'). It aligns with readOnlyHint=false and destructiveHint=false, and gives the agent a realistic sense of the side effects of saving.

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

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

One compact sentence with no filler. All three key behaviors—save, regenerate thumbnail, flush—are front-loaded and necessary.

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

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

For a zero-parameter save operation, the description is complete: it identifies the resource and the persistence behavior. No output schema is present, but no return-value documentation is essential for a straightforward save command.

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

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

The tool has zero parameters and the empty schema is fully covered, so there is nothing for the description to add about arguments. The baseline of 4 for no parameters is appropriate.

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

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

Clearly states the action (save), the target resource (open project), and key side effects (regenerate thumbnail, flush to disk). The behavior is unambiguous and distinct from siblings like screenshot, export, or backup.

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

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

The description makes the invocation context clear: use this when the open project should be persisted to disk. It does not explicitly name alternative tools such as export or backup, but the operation's purpose is specific enough to avoid major confusion.

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

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

Annotations indicate readOnlyHint=true, so no contradiction; the description adds value by clarifying that this captures the actual window and saves a file whose path is returned. It does not disclose details like window focus behavior or failure states, but for a non-mutating capture tool this is 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.

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

The description is a single focused sentence that front-loads the action and purpose. Every phrase earns its place, with no redundant or vague wording.

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

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

For a zero-parameter capture tool, the description adequately states input (none), what it does, and what it returns (image and file path). It does not mention prerequisites such as the app being open, but this is inferable from sibling tools and does not undermine correct invocation.

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

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

There are zero parameters, so the schema carries no burden. The baseline of 4 is appropriate because the description does not need to clarify any parameter details.

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

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

The description identifies a specific action ('Capture the real ScratchJr window'), a clear resource, and a concrete purpose ('for visual verification'). It also states the return value (image and saved file path), making it easy to distinguish from siblings like status or get_project.

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

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

The description implies when to use this tool ('for visual verification') but does not explicitly state when to prefer it over alternatives or mention prerequisites such as needing the ScratchJr app to be running/connected. Usage guidance is present but only implied.

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

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

Annotations already mark readOnlyHint=true and destructiveHint=false, covering the safety profile. The description adds behavioral value by stating the tool does not launch the app and provides a 'live' status check, which is extra context beyond what annotations convey. This is useful and not contradictory.

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

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

The description is a single 10-word sentence that is fully front-loaded with the main action ('Check') and includes only essential qualifiers. There is no fluff, and every word contributes to conveying the tool's purpose and key behavioral characteristic.

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

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

For a simple status-check tool with no parameters, annotations, or output schema, the description communicates purpose and a key side-effect detail. However, it does not describe the return value (e.g., what the status looks like—boolean, string, or details), which would be helpful for an agent to interpret the result. This is a minor but real gap.

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

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

The tool has zero parameters and the schema coverage is 100%, so the description does not need to explain parameters. Per the calibration baseline, a 4 is appropriate for zero-parameter tools—the description correctly omits parameter details and focuses on the tool's action.

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

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

The description uses a specific verb ('Check') and resource ('live ScratchJr connection') and adds the qualifier 'without launching the app,' which clearly differentiates it from sibling scratchjr_connect. An agent can immediately understand the tool's scope and how it differs from other connection-related operations.

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

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

The phrase 'without launching the app' implies this is a safe, lightweight check that can be performed anytime, but there is no explicit 'when to use' or 'use this instead of' guidance. The distinction from scratchjr_connect is implied rather than stated, so the usage context is present but not fully explicit.

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

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

The description discloses the main behaviors: stopping scripts and optionally resetting characters. It adds this context to the minimal annotations (readOnlyHint=false, destructiveHint=false), but it does not explain side effects such as whether the project remains open or whether any project data is changed.

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

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

The description is one short sentence, front-loads the primary action, and then adds the optional parameter context. No words are wasted.

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

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

For a single-boolean-parameter tool with no output schema, the description covers the essential behavior and parameter effect. It could be slightly more explicit about the scope ('all scripts in the current project') but is otherwise sufficient for correct invocation.

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

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

With 0% schema description coverage, the description carries the burden for the 'reset' parameter. It clearly links 'reset' to resetting characters to their starting positions, which is meaningful beyond the bare schema default of false.

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

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

The description states a clear action ('Stop scripts') and a distinct optional behavior ('reset characters to their starting positions'), which differentiates it from siblings like scratchjr_run_project and scratchjr_click_character. The resource scope is implied by the project name and the action is concrete.

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

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

The description does not state when to use this tool or compare it with alternatives such as scratchjr_run_project or scratchjr_status. It gives no explicit conditions, prerequisites, or exclusions, leaving the agent to infer usage from the tool name.

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