x_api_get_compliance_jobs

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

With no annotations provided, the description fully carries the transparency burden. It explicitly declares the read-only risk, bearer token prerequisite, environment-selection behavior via scopeTenantId plus exactly one of scopeUserId/scopeAccountId, and the role of credentialKey. It also lists common failure conditions, expected response shape, and a safety warning about sensitive data—extremely thorough.

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 organized with clear section labels and includes an example, which aids scanning. But it has redundancy: 'Use when: Get Compliance Jobs' duplicates the opening sentence, and 'Risk: read-only' is repeated in 'Safety warnings. The length could be reduced without losing information.

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 tool's complexity (8 parameters, no output schema, no annotations), the description covers prerequisites, response shape, failure conditions, environment behavior, and a concrete example. It does not explicitly differentiate from the by-id sibling tool, and some parameter semantics are incomplete, but overall it provides a robust operational picture.

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 0%, so the description must compensate. It explains type and status parameter formats, and the environment-selection role of scopeTenantId/scopeUserId/scopeAccountId/credentialKey. However, it does not explain authorizationKey or preferredAuthType semantics, leaving two of the eight parameters without meaningful description.

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 begins with 'Get Compliance Jobs.' which directly restates the tool name without adding specificity. It does not clarify whether this lists all jobs or retrieves a single job, nor does it distinguish from the sibling tool x_api_get_compliance_jobs_by_id. The 'Use when' section repeats the same tautology.

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 'Do not use when' section offers useful direction, telling the agent to prefer x_schema_discovery or x_query_suggestion for exploration. However, the 'Use when' is generic ('Get Compliance Jobs') and provides no explicit comparison to x_api_get_compliance_jobs_by_id or other compliance-related tools, leaving some ambiguity about the intended use case.

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