Sideways

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

Annotations already indicate readOnlyHint=true, and the description adds useful behavioral context: the result is random and returned as a 'labeled strategy card.' It also frames the intended outcome ('shift your perspective and break through blocks'), which goes beyond the structured data. The phrase 'make destructive moves' is clearly metaphorical herealert but not a 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?

The description is concise and front-loaded with the core action, but contains some redundancy between 'Best for injecting energy and unpredictability' and the later 'Use this when' list. Slightly tighter phrasing would improve it.

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 tool, the description fully covers what the tool does, when to use it, and what it returns. Nothing critical is missing for an agent to invoke it correctly without 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?

The tool has zero parameters and schema description coverage is 100%, so there is no parameter ambiguity. The description still usefully mentions 'random' and the returned card, satisfying the baseline for a no-parameter 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?

Description states 'Get a random Disrupt strategy' with a specific verb and resource, and clearly distinguishes it from siblings by naming the 'Disrupt' category. The purpose is immediately identifiable.

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?

Provides explicit use cases: 'when stuck in safe patterns, avoiding risk, or when work feels too polished or predictable,' and a direct 'Use this when' list. This makes it easy for an agent to decide when to invoke this tool versus the other sideways category 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?

Annotations already declare readOnlyHint=true, so safety is covered. The description adds useful behavioral context: the result is random and returns a 'labeled strategy card' meant to shift perspective. This goes beyond the structured annotations and helps set expectations for invoking the 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 front-loaded with the main action, but there is noticeable redundancy: 'Use when too much in your head' overlaps with 'physical, sensory, body-based approaches' and 'Best for grounding abstract work in physical reality.' The content is helpful but not every sentence 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 zero-parameter tool with no output schema, the description is reasonably complete: it explains when to use it, what kind of result to expect ('labeled strategy card'), and how it helps ('break through blocks'). It does not detail the exact card format, but that is not essential 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?

The tool has zero parameters and schema description coverage is 100%, so there is no parameter ambiguity to compensate for. The description appropriately focuses on behavior and use cases rather than 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 leads with 'Get a random Embody strategy', specifying a clear action and resource. It also differentiates this tool from siblings like disrupt or expand by naming physical, sensory, body-based approaches as the domain, so an agent can identify which category tool to call.

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 explicit use conditions: 'Use when too much in your head, experiencing physical tension, or disconnected from intuition' and 'Use this when: physical, sensory, body-based approaches to creative problems.' It does not explicitly state when not to use it or name an alternative tool, but the context is clear enough for selection among siblings.

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 this as read-only and non-open-world, and the description adds that the tool returns a randomly selected labeled strategy card. This is sufficient for a side-effect-free creative tool; 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?

The guidance is mostly well organized, but there is redundancy: 'breaking self-imposed limitations' and 'break through blocks' convey the same idea, and 'Use when' plus 'Use this when' split related guidance unnecessarily. It could be tightened without losing 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?

For a zero-parameter, read-only random generator with no output schema, the description covers what it does, when to use it, and what it returns. It could be slightly clearer about the exact shape of the 'strategy card', but nothing critical is missing 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?

The tool has zero parameters and full schema coverage, so the description does not need parameter details. The baseline for a no-parameter tool is 4, and nothing is missing here.

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 opens with 'Get a random Expand strategy', a specific verb and resource, and the category name 'Expand' distinguishes it from the sibling category tools. The title 'Sideways: Expand' reinforces the resource 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?

Provides explicit triggers ('when solutions feel too minimal, when avoiding decisions') and concrete use-case keywords ('add more, elaborate, embrace abundance, do both'). It does not explicitly contrast with the siblings, but the category names and context make the selection clear enough.

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 this as read-only, so the description doesn't need to cover safety. It adds useful behavioral context by noting the result is random and that it 'Returns a labeled strategy card,' which goes beyond what the annotations specify. 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?

The description is short and front-loaded with the core purpose. It is slightly repetitive, restating the 'use this when' guidance twice, but every part is otherwise useful and the overall length is appropriate.

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, read-only, zero-parameter tool, the description covers what it does, when to use it, and what it returns. There is no output schema, so the 'labeled strategy card' mention helps set expectations, though the exact card structure is not described.

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 coverage is 100%, so there are no parameter details to document. The description appropriately implies no input is needed by saying 'Get a random' strategy, which is the expected baseline 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?

The description opens with a specific verb and resource: 'Get a random Pause strategy.' The 'Pause' category clearly distinguishes it from sibling tools like get-sideways-strategy-category-disrupt or reframe, without needing to open their schemas.

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?

It gives explicit use cases: 'when rushing, feeling frantic, or unable to see the forest for the trees' and 'rest, reflect, step back, examine, take breaks.' It does not explicitly name sibling alternatives or state when not to use them, but the context is clear enough for an agent to route correctly.

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 readOnlyHint true and no destructive behavior, the safety profile is already covered. The description adds meaningful behavioral context by disclosing that the result is random and that it returns a 'labeled strategy card' as the output, which goes beyond what annotations alone provide.

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 front-loaded with the core operation and then provides usage guidance. It is slightly redundant—'Best for cutting through noise and finding the core' overlaps with the earlier complexity/clarity phrasing—but overall each section earns its place and the length is appropriate for a zero-parameter tool.

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 zero-parameter tool with no output schema, the description is complete: it states what the tool does, when to use it, what triggers it, and what it returns. There is no missing information an agent would need 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 baseline is 4. There is no parameter semantics burden, and the description correctly avoids inventing any. The behavior of returning a random strategy is clear without needing parameter documentation.

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 opens with a specific verb and resource: 'Get a random Reduce strategy.' The category name 'Reduce' and the usage focus on subtracting/simplifying clearly distinguish it from siblings like disrupt, expand, and reframe. An agent could correctly select this tool without opening other definitions.

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 explicit when-to-use context: 'overwhelmed by complexity', 'too many options', 'clarity is needed', and a list of trigger terms like simplify, subtract, remove, clarify, focus on essentials. It does not mention when not to use it or name alternative sibling categories, so it stops just short of full 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?

Annotations already declare readOnlyHint=true, so the agent knows this is a safe read operation. The description adds that it returns a 'labeled strategy card' and is random, which is useful behavioral context. However, it doesn't disclose details like whether repeated calls can return the same strategy or any rate limits, but for a random read-only tool this is acceptable.

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 reasonably concise and front-loaded with the core action ('Get a random Reframe strategy'). The repeated 'Use this when' phrasing is slightly redundant but not bloated. Every sentence contributes to usage 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 zero-parameter, read-only tool with no output schema, the description covers the essential context: what it does, when to use it, and what to expect in return. It doesn't explain the difference between Reframe and sibling categories, but the category name and purpose are sufficient for basic selection.

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 is trivially complete. The description adds value by explaining what the returned card contains (a labeled strategy) and the purpose, which helps the agent understand the output even without an output 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 tool returns a random Reframe strategy and is for shifting perspective or breaking mental ruts. It distinguishes itself from siblings by naming the 'Reframe' category, though it doesn't explicitly contrast with sibling 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 provides explicit use cases: when stuck in a single way of thinking, facing opposition, or needing a different angle. It says 'Use this when' and lists perspective changes, reversing assumptions, and adopting alternative viewpoints. It doesn't mention when not to use it or name alternatives, but the context is clear enough.

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