sb3_list_commentsRetrieve all comments attached to a sprite in a Scratch project. Use this to inspect or extract sprite-level notes during project analysis.
List sprite comments. (proxied)
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
| Name | Required | Description | Default |
|---|---|---|---|
| result | Yes |
Changes observed during successful MCP inspections.
v1.0.0Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations, so the description carries the full burden of behavioral disclosure. 'List' implies a read-only operation and 'proxied' hints at a relayed request, but there is no explanation of what proxying means, whether an active project or selected sprite is required, or any side effects. These gaps are not compensated by 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?
The description is only four words plus a parenthetical, and every element is relevant. It is front-loaded with the core operation and avoids any fluff. 'proxied' is terse but not redundant.
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 list tool with an output schema, the description is minimally viable, but it leaves the agent without context about active project/selected sprite requirements, the meaning of 'proxied', or the relationship to sibling comment tools. It is sufficient for a simple call but not fully complete.
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 an empty schema, so the baseline is 4 and the description does not need to document parameter details. Nothing about parameters is missing or misleading.
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 ('List') and resource ('sprite comments'), and the 'sprite' qualifier distinguishes it from social comments and from sibling mutation tools like sb3_add_comment, sb3_set_comment, and sb3_remove_comment. The name and description together leave no ambiguity about the operation.
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 guidance is given for when to use this tool instead of alternatives. It does not mention that this is the read counterpart to sb3_add_comment/sb3_set_comment/sb3_remove_comment, nor how it differs from social_get_comments. The agent must infer usage from the tool name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.