select_system_compliance_frameworks

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

With no annotations provided, the description carries the full burden. It explicitly discloses that the tool is 'Mutating' and 'sets the system's active frameworks', and it notes the 'Requires PRO tier' access constraint. While it does not detail reversibility or edge cases, the mutation effect and access requirement are clearly stated, which is strong for a mutating tool without annotation support.

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: it opens with the core action, then adds access and mutation warnings, then provides sibling differentiation and follow-up tool references. Every sentence contributes meaningful guidance without padding.

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 description covers the tool's purpose, mutation behavior, access requirement, relationship to the sibling tool, how to discover input values, and where to view results. Given the output schema exists, return values need not be described. This is complete for the tool's complexity.

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 defines system_id and framework_ids with useful descriptions and an example. The description adds context for discovering framework IDs via list_compliance_frameworks, which is helpful. However, the server_version parameter is undocumented (67% schema coverage) and the description does not explain it, leaving a gap.

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 'Select (activate)' and the resource 'compliance frameworks for a system', with the purpose 'for portfolio-level compliance reporting'. It explicitly distinguishes itself from the sibling tool select_compliance_frameworks by noting the system-level scope versus threat-model-level scope.

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 guidance: states it is the system-level counterpart to select_compliance_frameworks (which operates on a single threat model), tells users to discover framework IDs with list_compliance_frameworks, and directs them to get_system_compliance_report for viewing results. This clearly frames when to use this tool versus alternatives.

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