jira_default_project_key

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds modest context: the governed-authority routing and that effect must be 'read' with Spring verification. The phrase 'approval_ref: Approved platform task UUID when resuming a write' introduces write-related language, which is mildly confusing for a read-only operation, but it describes the parameter rather than claiming the tool writes.

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 Args block is tight and scannable, but the opening line is redundant, repeating the tool name twice ('default_project_key' and 'jira.default_project_key'). The routing sentence earns its place, but the first sentence could be deleted entirely without loss of 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?

All parameters are described, annotations cover safety and idempotency, and an output schema exists so return values need no explanation. However, the missing functional purpose is a significant completeness gap: an agent deciding whether to invoke this tool cannot tell what it produces or when it is relevant. For a tool with 0% schema coverage and no title, this is only minimally adequate.

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 carries the full burden, and it does define all 7 parameters with semantic glosses (e.g., 'Authenticated Project UUID', 'Project-bound connector account alias', 'Stable business-action identity'). This meaningfully exceeds what the schema provides, which only lists titles and defaults. Some glosses remain jargon-heavy, but the compensation for zero schema coverage is solid.

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 'Jira connector operation `default_project_key`', which merely restates the tool name and provides no functional verb or resource. The only substantive sentence, 'Routes only through the exact project/account governed connector authority', describes a routing constraint rather than what the operation does. An agent cannot determine from this text that the tool retrieves a default Jira project key.

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?

No when-to-use or when-not-to-use guidance is given, and no alternative tools are named despite close siblings like jira_default_board_id, jira_get_project, and jira_list_projects. The routing-authority sentence is a mechanism constraint, not selection guidance. An agent must infer entirely from context when this tool is the right choice.

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