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 reveal a persistent side effect ('Saves the connection info'), but it does not mention whether it validates the credentials, overwrites an existing named instance, or how the stored connection affects future calls. This is a moderate gap for a state-changing setup tool.

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, focused sentences communicate the core action and the persistent side effect with no filler. The key verb and resource are front-loaded, and every word contributes to understanding.

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 three-parameter configuration tool, the description is mostly sufficient, but without annotations it leaves ambiguity around whether 'connect' actively tests the connection or merely stores credentials. It also omits what happens if the same name is reused or whether the API key is stored securely, so an agent cannot fully anticipate side effects.

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%, so the schema already documents all three parameters. The description only refers to them as 'connection info' without adding format, validation, or usage details beyond the schema, meeting the baseline for fully covered parameters.

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 action 'Connect to a Memos instance' and the side effect 'Saves the connection info for future use,' identifying the resource and purpose. It is distinct from sibling tools like list_instances and disconnect_instance, though it does not explicitly contrast itself with 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 description conveys when to use the tool: when establishing a connection and persisting it for subsequent operations. It does not explicitly address alternatives or exclusion criteria, but the context is clear enough for an agent to identify this as a setup/configuration action rather than a data operation.

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?

No annotations are provided, so the description carries the full burden of behavioral disclosure. It only states the action and omits any side effects, persistence semantics, prerequisites, visibility behavior, or return value. An agent cannot tell from the description what happens after the call succeeds or what constraints apply.

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 with zero wasted words. It could usefully add more context, but as measured purely by conciseness and structure, it is compact and immediately understandable.

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?

Given no annotations, no output schema, and 4 parameters, this minimal description is insufficient. It does not mention that an instance is required, what the created memo looks like in response, whether visibility or pinning are optional, or any operational context such as needing a connected instance. The schema covers parameter names but not the tool's broader invocation context.

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%, so the input schema already documents all four parameters, including defaults for pinned and visibility. The description itself adds no parameter meaning beyond reinforcing that content is provided, but the schema carries the weight adequately.

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?

Uses a specific verb and resource: 'Create a new memo.' This clearly distinguishes the operation from sibling mutations like update_memo and delete_memo. However, it restates the tool name almost verbatim and adds no detail about what a memo is or what creating one entails.

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 this is the tool to use when the agent needs to create a memo, but it provides no explicit guidance on when to prefer it over alternatives, what preconditions exist (such as a connected instance), or when not to use it. The context is inferable from the name and siblings but not 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?

No annotations are provided, so the description carries the full burden of behavioral disclosure. It only states that a shortcut is created; it does not mention permissions, whether duplicate titles are allowed, whether the filter must be valid CEL, or what the result of the operation is. This is minimal behavioral information for a mutation.

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 with no filler. The parenthetical '(saved filter)' earns its place by clarifying the resource type. It is concise, though it sacrifices some useful behavioral context for brevity.

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?

With no annotations and no output schema, the description should supply more context about side effects, return values, and prerequisites. The schema tells an agent what parameters to send, but it does not explain the operational context, such as needing a connected instance or what success looks like. A create operation needs more than this.

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%, so the baseline is 3. The description adds a small amount of semantic context by calling the shortcut a 'saved filter,' which suggests how 'filter' is used, but it does not provide meaningful additional parameter-level details beyond the 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 clearly states the verb ('Create'), the resource ('a new shortcut'), and clarifies the concept by explaining it as a 'saved filter.' This distinguishes it from update_shortcut, list_shortcuts, and delete_shortcut without ambiguity.

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, no mention of prerequisites like connecting to an instance first, and no indication of when a shortcut should be created rather than updated or listed. The usage context is entirely absent.

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?

With no annotations provided, the description carries the full burden of behavioral disclosure. It only states the delete action and does not indicate whether deletion is permanent, whether it requires an active connection, what happens to related data, or any error/idempotency behavior. This is insufficient for a destructive operation.

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 extremely short and free of wasted words, which favors conciseness. However, it is under-specified rather than appropriately concise, since it omits meaningful operational details and does not add value beyond the tool name.

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 only two well-documented parameters, but the description lacks essential behavioral context for a delete operation, such as irreversibility, prerequisites, and consequences. The absence of annotations and output schema further increases the gap, making the description incomplete.

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 already describes both parameters ('Instance name' and 'Attachment name') with 100% coverage, so the baseline is 3. The description adds no further semantic detail about how the parameters relate or are used.

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 'Delete an attachment.' is a direct restatement of the tool name delete_attachment, providing no additional meaning. It identifies the verb and resource, but because the name already conveys this, it is essentially tautological.

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 about when to use this tool versus alternatives such as upload_attachment or list_attachments, nor does it mention any prerequisites like having an instance connected. The tool is only identifiable by its name, not by any contextual direction.

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?

With no annotations, the description carries the full burden of behavioral disclosure. 'Delete a memo' only names the destructive action and does not mention permanence, cascading effects, required permissions, or error behavior. It gives minimal signal but stops far short of transparently describing consequences.

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 short sentence with no filler or redundancy. It is front-loaded and easy to parse, though it is so brief that it leaves important behavioral context for other dimensions to cover.

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 destructive tool with no annotations and no output schema, this description is under-specified. It omits whether deletion is permanent, whether associated data is removed, and what happens on invalid or missing memos. The schema documents parameter names but not operational context.

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%, so both instance and memoName are already documented in the schema. The description adds no parameter-specific meaning, which is acceptable under the baseline for complete schema coverage.

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 action (delete) and the resource (memo), which is enough to distinguish it from memo-related siblings like get_memo, create_memo, and update_memo. However, it is minimal and does not add any distinguishing context beyond the obvious resource.

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 about when to use this tool versus alternatives, nor any mention of prerequisites or conditions. The agent can only infer that it should be used when the goal is to delete a memo, but no exclusions or alternative routing are provided.

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?

No annotations are provided, so the description carries the full burden of disclosing behavior. 'Delete' indicates a destructive operation, but the description does not state whether deletion is permanent, whether the shortcut must exist, whether related data is affected, or what happens on success or failure. This is minimal behavioral disclosure.

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, short sentence that is front-loaded and free of filler or redundancy. It is concise and readable, though terse to the point of under-specification; it still earns its place because no title is provided.

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?

Given the low tool complexity and full parameter coverage, the schema plus description provide enough for a basic invocation. However, with no annotations and no output schema, the description remains incomplete about side effects, prerequisites, and when to use this tool instead of related shortcut or delete tools.

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 covers 100% of parameters with descriptions for 'instance' and 'shortcutName', so the baseline is 3. The description does not add any meaning beyond those schema descriptions, but no compensation is needed given full schema coverage and the simple parameter set.

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 and resource, 'Delete a shortcut,' which clearly identifies the operation and distinguishes it from sibling delete tools by naming the shortcut resource. It lacks added scope or nuanced context beyond the tool name, but it is not vague or tautological.

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 no guidance on when to use this tool versus alternatives like update_shortcut, list_shortcuts, or delete_memo. There are no stated prerequisites, exclusions, or conditions or alternative routing. The only implied usage context comes from the tool name itself.

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?

No annotations are provided, so the description carries the full burden of behavioral disclosure. It indicates a removal action but does not explain whether this deletes local configuration, affects remote data, requires authentication, or is reversible.

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 concise sentence with no wasted words. It is front-loaded with the action and target, though it sacrifices useful detail for brevity.

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 one-parameter tool, the description is minimally adequate: it names the action and target. However, with no annotations and no output schema, it leaves some ambiguity about side effects and preconditions, so it is 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?

Schema description coverage is 100%, and the parameter is already described as 'The name of the instance to disconnect.' The description adds little beyond the schema, aside from reinforcing that the instance must be 'connected.' This meets the baseline but provides no extra semantic depth.

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 ('Remove') and a specific resource ('a connected Memos instance'). It clearly differentiates this tool from sibling tools like connect_instance and list_instances without needing to open the schema.

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 explicit guidance on when to use this tool versus alternatives. It only implies it applies to 'connected' instances, but does not mention connect_instance as the counterpart or list_instances as a way to find the name.

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?

With no annotations provided, the description itself carries the behavioral disclosure burden. 'Get' clearly signals a read-only, non-mutating operation, but the description does not disclose behavior such as error handling for nonexistent memos or the return format, though some of that may be inferred.

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, direct, front-loaded sentence with no filler or redundant information. 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 straightforward single-resource retrieval tool with only two required parameters and full schema coverage, the description provides sufficient context to call it correctly. It could be enhanced with note about return values or not-found behavior, but the core purpose is clear.

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%, so the schema already documents both `instance` and `memoName`. The description reinforces the role of `memoName` but adds no new meaning beyond the schema, so 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 a specific verb ('Get') and identifies the exact resource ('a specific memo') plus the selection key ('by its name'). This clearly distinguishes the tool from list_memos, which presumably returns all memos, though it doesn't explicitly name that sibling.

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 'by its name' implies the tool is for retrieving a single known memo rather than listing all memos, providing an implicit usage context. However, it does not explicitly state when to prefer this tool over list_memos or mention alternatives.

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?

No annotations are provided, so the description carries the full behavioral burden, but it only restates the tool's name. It does not disclose permissions, connection requirements, response format, pagination, or the scope of 'all attachments.'

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, filler-free sentence with the core action front-loaded. It is appropriately minimal for a simple one-parameter listing tool, though it sacrifices explanatory depth.

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?

With no output schema and no annotations, the description is too sparse to be complete. It fails to clarify whether the required instance scopes the results, whether a connection must be active, or what the response contains.

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%, so the single 'instance' parameter is already documented. The description adds no extra meaning about how the instance parameter affects the listing, so the baseline of 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?

States the verb 'List' and the resource 'attachments,' which clearly separates it from sibling upload/delete operations. However, 'all attachments' is ambiguous given the required instance parameter: it is unclear whether the listing is global or scoped to one instance.

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 no guidance on when to use this tool versus alternatives such as upload_attachment, delete_attachment, or list_memos. It also does not mention that connecting an instance first may be a prerequisite, which sibling tool names imply.

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?

No annotations are provided, so the description itself must convey safety and behavior. 'List all connected' clearly signals a read-only operation scoped to connected instances, but it does not mention output format, pagination, or any side effects; acceptable for a zero-param list, but minimal.

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 with no filler; the verb, resource, and scope all appear up front. 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?

Given zero parameters and no output schema, the description covers what the agent must know to invoke the tool correctly. It does not describe the list shape, but for a simple enumeration of connected instances that is not a blocking 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 takes zero parameters, so there are no parameter semantics to document. The baseline of 4 applies because the schema is empty and no description compensation is needed.

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?

Description begins with the specific verb 'List' and a concrete resource, 'all connected Memos instances,' so an agent knows exactly what the tool returns. This is distinct from sibling list_memos (memos inside an instance) and connect/disconnect_instance, so there is no ambiguity.

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?

Usage is implied: call this when you need to enumerate the Memos instances that are currently connected. However, the description never explicitly states when to prefer it over list_memos or connect_instance, and it names no alternatives or exclusions.

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?

With no annotations, the description must carry behavioral weight. 'List' signals a read-only operation and 'from one or all connected instances' adds multi-instance scope, but the description does not mention pagination behavior, return format, or any implications of querying all instances. It 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 with no filler. Every word earns its place, and the most important scoping information ('one or all connected instances') is stated 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 list operation with five optional parameters, a rich schema, and no output schema or annotations, the description is nearly sufficient. It identifies the resource and scope, while the schema covers the parameters; the main gap is the lack of guidance about return structure or behavior when querying all instances.

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%, so all five parameters are already documented with meanings and defaults. The description adds no parameter-level detail beyond the schema, which matches the baseline 3 for high-coverage schemas.

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 ('List') and a precise resource ('memos'), and scopes it to 'one or all connected Memos instances.' This clearly separates it from sibling tools like get_memo (single memo) and list_instances (instances, not memos), so an agent can tell what it does without opening the schema.

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 operation itself implies when to use it — when memos need to be retrieved — but the description never states exclusions or points to alternatives such as get_memo for a single memo. It gives the scope (one/all instances) but not explicit when-to-use-versus-sibling guidance.

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?

No annotations are provided, so the description carries the full burden of behavioral disclosure. It reveals nothing beyond the basic operation: no output format, pagination, sorting, authorization requirements, or side effects. This is minimal even for a read-only list operation.

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

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

The description is a single, front-loaded sentence that directly states the operation without filler. Every word contributes to understanding the tool's purpose.

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?

This is a functionally adequate description for a low-complexity list tool with fully described parameters. However, with no output schema and no annotations, it does not disclose response shape or behavioral details such as whether shortcuts are returned in any particular order or limited by pagination. It meets the minimum viable standard but leaves clear gaps.

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%, with both 'user' and 'instance' already documented in the input schema. The description adds no new parameter semantics; its 'for a user' phrasing merely restates the 'user' parameter, so the baseline score of 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 a specific verb ('list') and resource ('shortcuts') with an explicit scope ('for a user'), making the tool's function immediately clear. It also distinguishes itself from sibling list tools like list_memos, list_tags, and list_instances without needing extra context.

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 versus alternatives, nor does it mention prerequisites or exclusion conditions. The only usage signal is implicit in the tool name and the simple phrasing, which is not enough to help an agent decide between related listing tools.

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 verb 'List' signals a read-only operation and the phrase 'from memos' clarifies the data source, but with no annotations the description carries the full burden. It does not disclose potential pagination, duplicate handling, authentication requirements, or what exactly constitutes a tag beyond the name. It is adequate but minimal for a simple listing tool.

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 sentence with no redundant words. 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.

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

The tool is low-complexity with one optional, fully documented parameter and no nested objects. The description gives the core behavior and data source, while the schema covers instance selection. The absence of an output schema leaves the return format implicit, but for a simple list-all-tags operation the definition is complete enough.

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%, with the lone optional parameter clearly documented as selecting an instance or querying all instances. The description adds no parameter-specific detail, but the schema already carries the necessary meaning, so the baseline score of 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 a specific verb ('List') and a clear resource ('all tags from memos'), making the purpose unmistakable. It also distinguishes this tool from siblings like list_memos, list_shortcuts, and list_attachments by naming a unique resource type.

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 the tool should be used when an agent needs all tags derived from memos, but it does not provide explicit when-to-use/when-not-to-use guidance or name alternatives. The context of sibling tools makes the intended use reasonably clear, but no direct routing guidance is 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?

No annotations are provided, so the description carries the full burden of behavioral disclosure. It only states that the tool updates a memo, without disclosing whether updates are partial or full replacements, whether omitted fields are left unchanged, or whether permissions or side effects apply.

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 clear sentence with no filler. It is appropriately front-loaded for naming the action and object, though it could affordably include sibling differentiation or update behavior without becoming bloated.

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 mutation tool with no annotations, no output schema, and six parameters, the description is too thin. It does not explain update semantics, optional-field behavior, or how this tool interacts with the memo lifecycle compared to create_memo or delete_memo.

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%, so the schema already documents all six parameters, including enums for state and visibility. The description adds no parameter-level meaning, but the baseline of 3 applies because the schema handles the heavy lifting.

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?

Description states a clear verb and resource: 'Update an existing memo.' It distinguishes itself from sibling tools like create_memo, delete_memo, and get_memo by explicitly focusing on modifying an existing memo.

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 provided about when to use this tool versus alternatives. The description does not mention exclusions, prerequisites, or that create_memo should be used for new memos. The 'existing' wording implies some context but does not explicitly compare against any sibling.

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?

With no annotations present, the description carries the full burden of behavioral disclosure. It merely states that an existing shortcut is updated but does not explain whether fields are merged or overwritten, what permissions are required, or whether the operation is reversible.

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 short sentence with no filler or redundant content. It is appropriately sized for a simple CRUD operation and front-loads the core action.

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?

Despite complete parameter documentation, the description lacks essential behavioral context for a mutation tool with no annotations or output schema. An agent doesn't know whether the update is partial or full, or what response to expect.

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%, so every parameter is already documented in the schema. The description adds no extra meaning beyond 'update', 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.

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

The description clearly identifies the action ('update') and the resource ('existing shortcut'), which distinguishes it from sibling create/delete/list tools. It is concise and states the core purpose, though it does not specify which attributes are updatable.

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 provided about when to use this tool over create_shortcut, list_shortcuts, or other alternatives. The only implied context is that the shortcut must already exist, but no explicit selection criteria 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?

No annotations are provided, so the description carries the full burden for behavioral disclosure, but it only says 'Upload a new attachment.' It does not mention side effects, permissions, overwrite behavior, or what happens after a successful upload.

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 short and front-loaded, but the brevity reflects under-specification rather than informative economy. The single sentence essentially restates the tool name without adding useful detail.

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?

With no annotations, no output schema, and five parameters (four required), a one-sentence description is incomplete. It does not explain the return value, the final state of the attachment, or how the upload fits into the memo workflow.

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 documents all five parameters with descriptions, including base64 content and memo association examples. The tool description itself adds no parameter semantics, so with 100% schema coverage the baseline score of 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 states a specific verb and resource: 'Upload a new attachment.' It is distinct from sibling list/delete attachment tools, though it does not mention the optional association with a memo.

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 about when to use this tool versus list_attachments or delete_attachment. The intended workflow context must be inferred from parameter names and sibling tool names.

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