getScenarioInfo

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

No annotations exist, so the description alone must disclose behavioral traits. It only states that it retrieves details, implying read-only, but does not mention error behavior, secret handling defaults, or whether it requires any permissions. This is a significant gap for a tool without 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?

Single sentence front-loads the purpose and lists the data returned. No filler or repetition.

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 getter with two well-documented parameters, the description covers the main purpose and return content (actions, parameters, dependencies). However, lack of output schema and annotations means the description should also clarify error handling and secret inclusion behavior, which it partially inherits from the schema but doesn't explicitly state. Still, it's adequately complete for basic use.

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 documents both parameters fully: 'name' as scenario name and 'includeSecrets' with default. The description adds no additional meaning to either parameter, merely using the word 'parameters' generically, which could confuse with scenario parameters vs tool 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?

Clear verb+resource: 'Get scenario details' specifies the action. The additional list 'actions, parameters, dependencies' clarifies the scope of details, distinguishing from siblings like listScenarios or searchScenarios which focus on listing/searching rather than fetching full details of a specific scenario.

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 use when you need full scenario details by name, but it doesn't explicitly state alternatives or exclusions. There are siblings like listScenarios and searchScenarios, but the description's mention of 'details' suggests the use case. Still, no explicit guidance on when to use this vs alternatives.

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