get_phishing_campaign_scenario_campaign

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

No annotations are provided, so the description must carry the behavioral burden. The verb 'Get' and the GET endpoint imply a read-only operation, and parameter placement is described. However, it doesn't disclose any additional behaviors like rate limits, auth requirements, or response shape, though an output schema exists to cover return format.

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 with no filler. The purpose is front-loaded, followed by the endpoint and parameter placement guidance. 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?

The tool is a simple GET with three optional parameters, and an output schema is present. The description covers the endpoint, parameter placement, and the relationship being fetched. It doesn't explicitly contrast with get_phishing_campaign_scenario_scenario, but the name and description make the distinction clear. Minor gaps like auth or error handling are not critical for a basic read operation.

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 0%, so the description must compensate. It does provide guidance: route IDs go in path_params, and filtering/pagination/sorting/include values go in query. This adds meaning beyond the generic object schemas, but it doesn't specify which route IDs (though the endpoint implies phishingCampaignScenarioId) or list concrete query parameters. Body is not mentioned, leaving some ambiguity.

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 fetches the campaign associated with a campaign-scenario, naming the exact resource and relationship. It also provides the underlying endpoint, and the name distinguishes it from siblings like get_phishing_campaign_scenario_scenario, so an agent can tell them apart.

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 context is clear: use this when you need the campaign linked to a specific campaign-scenario. It gives explicit instructions on where to place route IDs (path_params) and query options (filtering, pagination, sorting, include values). However, it doesn't explicitly list when not to use it or compare to alternatives, though the naming implies the distinction.

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