Skip to main content
Glama

Select Jira site

jira_select_site

Selects the default Jira site by cloud ID, name, or URL and persists it across restarts, so all Jira tools use the same site.

Instructions

Chooses the default Jira site for all tools (by cloud id, name, or URL). Persists across restarts.

Input Schema

NameRequiredDescriptionDefault
siteYesCloud id, site name, or URL such as 'acme.atlassian.net'.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A3.8/5.0
Behavior4/5

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

Annotations declare a non-read-only, non-destructive, open-world operation, and the description adds genuinely new behavioral context: the setting is global ('for all tools') and durable ('persists across restarts'). It does not say what happens on an unrecognized site value or whether the current selection is validated first, which keeps it short of a 5.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two short sentences, no waste, with the core action and the accepted input forms front-loaded and the persistence note second. Every clause carries information.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a one-parameter configuration setter with annotations present and no output schema, the description covers what it does, its scope, and its persistence. Only error/failure behavior for an invalid site string and any auth prerequisite are unstated.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% and the single parameter is already documented with examples ('acme.atlassian.net'). The description's 'by cloud id, name, or URL' restates the schema rather than adding resolution rules or precedence when the three forms conflict, so baseline 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource ('chooses the default Jira site') plus the accepted identifier forms, and the phrase 'for all tools' clarifies the global scope of the effect. It is clearly distinct from jira_list_sites or jira_connect, though it never names those siblings to make the contrast explicit.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Usage is implied by 'for all tools' — an agent can infer this should be called when it needs to pin a default site before other Jira calls. But there is no guidance on prerequisites (must jira_connect run first?), whether jira_list_sites should be used to discover valid values, or how this interacts with jira_auth_status.

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