jira-mcp

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v0.1.0
Disambiguation5/5
Each tool targets a distinct resource and action. For example, get_project vs get_all_projects, search_users vs get_all_users, and the three worklog tools (get_user_worklog, get_users_worklog, get_team_worklog) have clear scopes (single user, group, team) with no overlap.
Naming Consistency5/5
Tool names follow a consistent verb_noun pattern: get_* for retrieval, search_* for search, add_* for creation, create_issue, and find_* for lookup. No mixed conventions or vague verbs.
Tool Count5/5
19 tools is well-scoped for a Jira/Tempo integration covering projects, issues, users, teams, worklogs, and plans. Each tool serves a clear purpose without being too few or too many.
Completeness4/5
The tool set covers core workflows: project/issue retrieval, user/team discovery, worklog and plan queries, and limited write operations (add_worklog, create_issue, add_comment). Missing update/delete operations for issues, but the primary focus on reporting is well-supported.
Average 4.4/5 across 19 of 19 tools scored. Lowest: 3.4/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 16 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits. It only states the basic action without mentioning permissions, whether the comment is appended or replaces, or any side effects. The output schema existence is not leveraged to describe return values.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise (two sentences plus an Args section). However, the Args section uses non-standard formatting (adapted from docstring) rather than a clean prose description. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple 2-parameter tool with an output schema, the description covers parameter semantics but omits behavioral details like whether the comment is added to the issue's existing comments or replaces them, or any authorization requirements. Adequate but not thorough.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds meaning beyond the schema: 'issue_key' is explained with an example ('PROJ-123') and 'comment' is described as 'plain text / Jira wiki markup'. Given 0% schema coverage, this significantly aids understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Add a comment to a Jira issue' using a specific verb ('Add') and resource ('comment' with target 'Jira issue'). This distinguishes it from siblings like 'create_issue' or 'add_worklog'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives, such as when to add a comment versus update an issue or add a worklog. The description lacks any contextual advice on prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description must disclose behavioral traits. Only mentions default limit, but omits pagination, rate limits, authorization needs, or query timeout. Incomplete for a search tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Concise with an Args section. The first line is clear and front-loaded. Each sentence adds value without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With output schema present, return values are not required in description. However, missing usage guidelines and behavioral transparency make the description incomplete for a tool with moderate complexity (2 params, search operation).
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the description adds meaning: jql has an example ('project = PROJ AND status = "In Progress"') and limit specifies 'Maximum number of issues to return (default 50)'. Compensates well.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Search issues with a JQL query', specifying the verb (search), resource (issues), and method (JQL). This distinguishes it from sibling tools like 'get_issue' (single issue by ID) and 'search_users'.
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?
No explicit guidance on when to use this tool versus alternatives (e.g., get_issue for single issue retrieval). Usage is implied but no when-not-to-use or exclusions provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description must cover behavioral traits. It only states that it gets a project, with no mention of permissions, rate limits, error handling, or read-only nature.
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?
Extremely concise: two sentences for purpose and a clear list for parameters. No unnecessary words.
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?
Covers purpose and parameters well. Missing details on error handling (e.g., project not found) and permission requirements, but output schema handles return structure.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Adds significant meaning beyond schema: explains project_key accepts key or id with examples, and expand is a comma-separated list with examples. Schema coverage 0%, so description carries full parameter documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states it retrieves a single Jira project by key or id. Distinguishes from sibling 'get_all_projects' which lists all projects.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives. Implies use for one project but does not say when not to use or mention alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
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. It describes the search function and parameters but does not explicitly state read-only safety, pagination behavior, or authentication requirements. The search nature implies it is safe, but explicit disclosure is missing.
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?
The description is concise: one introductory sentence followed by a bulleted list of parameters with clear explanations. Every sentence adds value with no redundancy or fluff.
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 simple search tool with an output schema (not required to describe returns), the description covers parameters and behavior well. It could mention edge cases (e.g., empty results) but overall is adequately complete given tool simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description provides all parameter meaning: query as substring match, limit as max results (default 50), include_inactive for deactivated users. This fully compensates for the schema's lack of descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool searches Jira users by name, username, or email fragment. It specifies a concrete verb ('Search'), resource ('Jira users'), and search criteria, distinguishing it from siblings like get_all_users (which returns all users) and search_issues (which searches issues).
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?
The description implies usage for substring-based user searches but does not explicitly compare to alternatives like get_all_users for unfiltered retrieval or provide when-not-to-use guidance. No context on when to prefer search_users over other user-listing tools is given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It describes a read-only search operation with substring matching, but does not disclose additional behavioral traits such as authentication requirements or side effects. The existence of an output schema covers 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is structured into three paragraphs: purpose, usage example, and parameter list. Information is front-loaded and each sentence adds value. Could be slightly more concise, but overall well-organized.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (2 optional params, output schema present), the description is complete. It covers purpose, usage context with an example, parameter defaults, and links to a related sibling tool. No gaps identified.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
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 clearly explains both parameters: 'query' is a substring match defaulting to 'users', and 'limit' is the max number of groups defaulting to 20. This adds meaningful context beyond the schema's titles and defaults.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states 'Find Jira groups by name' and specifies the use case of discovering the license group name. It distinguishes from siblings like 'get_all_users' by explaining the tool is for finding groups when you don't know which group holds all users.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit context for when to use this tool: 'when you don't know which group holds all users' and suggests passing results to 'get_all_users'. It gives usage examples but does not explicitly state when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. 'Get' implies a read-only operation without side effects, but it does not explicitly state that it requires read permissions, is safe, or that no modifications occur. Lacks disclosure of rate limits or auth needs beyond typical Jira API expectations.
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 sentences with a clear structure: purpose statement followed by parameter documentation. No fluff, example provided, and critical information is front-loaded. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read tool with two parameters and an output schema, the description is complete. It covers input details and scope. Output behavior is handled by the existing output schema, so no need to describe return values.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, description compensates fully. It explains issue_key format with a concrete example and clarifies the fields parameter as an optional comma-separated list defaulting to all fields, adding significant meaning beyond bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states 'Get a single Jira issue by key', specifying verb, resource, and method. Example with key format (PROJ-123) reinforces exact usage. Distinguishes from siblings like search_issues (multiple issues) and create_issue (creation).
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?
Implies usage when you have a specific issue key, but does not explicitly contrast with alternatives like search_issues for batch retrieval or get_project for project details. No when-not-to-use guidance, though the narrow scope is inferred.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses important behavioral traits: the date range is inclusive, weekends and holidays are excluded using Tempo's calendar, and the breakdown parameter controls output detail. It does not mention read-only nature or authentication, but the core behavior is well-explained.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with an introductory sentence, a bullet list for arguments, and a note on return structure. It is efficient but slightly longer than necessary; however, every sentence adds value. No redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (date range, calendar, breakdown), the description covers all functional aspects. An output schema exists, and the description provides a high-level overview of return fields (plans, by_project, optionally by_day). No obvious gaps for an agent to misuse the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must compensate fully. It provides detailed semantics for all four parameters: username (Jira login), date_from and date_to (inclusive YYYY-MM-DD format), and breakdown (pass 'day' for daily breakdown). This adds essential meaning beyond the schema titles.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool fetches a user's plan allocations over a date range, answering a specific question. It distinguishes from the sibling tool 'get_users_plan' by focusing on a single user, and the verb 'get' combined with the resource 'user_plan' is precise.
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?
The description implicitly explains when to use the tool (to retrieve a user's planned hours for projects within a range) but does not explicitly mention when not to use it or when alternatives like 'get_users_plan' might be better. Usage context is clear but lacks exclusions or comparisons.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description explains server-side filtering, breakdown behavior, and default for exclude_absence. However, it does not mention authentication requirements or rate limits, which is acceptable given no annotations but lacks full transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is informative and well-structured with a clear parameter section. It is slightly verbose but each sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 6 parameters, no annotations, and an output schema, the description covers all necessary details (parameter formats, optionality, behavior) and references the API source.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
All six parameters are thoroughly explained with format, optionality, and behavior (e.g., breakdown options, exclusion default). This adds significant value beyond the empty schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns total hours logged by a user in a date range, optionally broken down. It uses specific verbs and resource identification, distinguishing it from siblings like get_users_worklog.
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?
The description implies usage for single-user worklog retrieval but does not explicitly state when to use this tool over alternatives like get_users_worklog or provide conditions for use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. It discloses that results are based on authenticated user visibility and includes parameters for including archived projects and expanding fields. It does not mention pagination or performance, but for a simple listing tool, this is adequate.
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?
The description is concise, front-loaded with the main purpose, and uses a bullet list for arguments. Every sentence adds value with no waste.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity (2 optional parameters, no nested objects) and the presence of an output schema, the description covers purpose, parameters, and visibility context completely. No return value explanation needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description fully explains both parameters: 'include_archived' as a boolean for including archived projects, and 'expand' as an optional comma-separated list with examples (description,lead,url). This adds significant meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'List all Jira projects visible to the authenticated user,' specifying the verb (List) and resource (all projects). This distinguishes it from siblings like 'get_project' which retrieves a single project.
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?
The description implies usage for listing projects but does not explicitly indicate when to use this tool versus alternatives like 'get_project' or other list tools. No exclusions or when-not-to-use guidance is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It explains the de-duplication process, default groups for Jira Server/DC limitations, and status filtering. It does not cover performance or permission requirements, but it is still substantial.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a clear opening sentence and bulleted args. It is slightly verbose but each sentence adds value. No redundancy.
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?
Given the tool has two simple parameters and an output schema is available, the description sufficiently covers the tool's behavior. It explains the unique need for the tool in Jira Server/DC environments.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, and the description fully covers both parameters: `groups` defaults to license groups, and `status` defaults to 'active' with clear definitions for values 'active', 'inactive', and 'all'. This adds significant meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states 'List all Jira users' and explains the unique mechanism of enumerating group memberships for Jira Server/DC, clearly distinguishing the tool's purpose from sibling tools like search_users.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It describes when to use the default behavior (union of Jira Software license groups) and how to target specific groups via the `groups` parameter. However, it does not explicitly state when not to use this tool or point to alternatives like search_users for name-based searches.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses local filtering behavior and case-insensitivity. No annotations provided, so description carries full burden — it reveals the underlying implementation (no server-side search) without contradicting any metadata.
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?
Five lines with clear structure: purpose first, then behavioral context, then usage hint, then parameter details. Every sentence adds value and no redundancy.
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?
Covers purpose, behavior, parameter semantics, and use case. Could mention handling no results or errors, but given output schema exists and tool is simple, this is adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Both parameters are described in args: 'query' as substring match to team name, 'expand' as optional comma-separated expand fields with example. Schema had 0% coverage, so description fully compensates.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
States 'Find Tempo teams whose name contains query (case-insensitive)' — specific verb, resource, and matching rule. Distinguishes from siblings like get_all_teams (lists all without filtering) and search_users/search_groups.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explains that no server-side search exists, so tool lists all teams and filters locally. Provides a concrete use case: converting team name to teamId for get_team_worklog. Lacks explicit 'when not to use' but context is sufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It describes the action and parameter but does not disclose permissions, pagination, or limits; however, being read-only is implied, and the expand parameter is explained.
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?
Description is extremely concise with front-loaded main purpose, then usage note, then parameter definition. Every sentence adds value with no waste.
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?
Output schema exists, so return values need not be detailed. The description covers purpose, usage, and parameter adequately, but lacks mention of authentication or potential limitations given no annotations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 0% coverage with no descriptions. The description adds meaning by explaining expand as optional comma-separated expand fields with examples, exceeding baseline of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states 'List every Tempo team' with specific fields (id, name, lead) and explicitly differentiates from sibling find_team, providing strong purpose clarity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use (discover teamId for get_team_worklog) and when to prefer alternative (find_team for name lookup), offering clear usage guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations present, so description carries burden. Discloses default flattened output shape and raw parameter effect. Mentions key is same as worker field. Does not address pagination or idempotence, but for a read-only list tool, the provided details are sufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is well-structured with clear sections. Includes URL, parameter explanations, and usage notes. Could be slightly more concise (e.g., floating the URL), but overall efficient and readable.
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?
Output schema exists, so return value details are not needed. Description covers default vs raw output and key mapping. Given sibling tools context, it provides enough information. Could mention pagination, but not essential.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, but description fully compensates. Explains team_id with data type and example (79). Explains raw parameter with its purpose and when to use it ('when you need fields not surfaced by default'). Adds meaning beyond raw schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states 'List all members of a Tempo team' with specific verb and resource. Distinguishes from 'get_all_users' by noting Tempo team vs Jira user group. References exact API endpoint: rest/tempo-teams/2/team/{team_id}/member/.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says when to use this tool ('List all members of a Tempo team') and when not ('not a Jira user group'), with alternative tool named ('see get_all_users for groups'). Additionally explains that the output 'key' field is used in per-user worklog tools, providing integration guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full disclosure burden. It explains the single-request behavior, inclusive date range, and breakdown nesting. While it lacks details on authentication, rate limits, or error handling, the core behavioral traits are adequately covered.
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?
The description is efficiently structured with a brief summary, behavioral explanation, and parameter list. Every sentence adds value, and the format is easy to parse. No redundancy or unnecessary verbosity.
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?
Given the tool's complexity (6 parameters, no annotations, output schema exists), the description covers most aspects: core function, comparison with siblings, and parameter details. The missing 'exclude_absence' parameter and lack of response structure summary (though output schema exists) prevent a perfect score.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description explains 5 of 6 parameters with added context (e.g., breakdown options, date format). However, it omits the 'exclude_absence' parameter, which is present in the schema but undocumented. Despite this gap, the description adds significant meaning beyond the schema's property titles.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: retrieving total hours logged by a group of users within a date range, per user. It distinguishes from siblings like get_user_worklog (singular) and get_team_worklog by emphasizing it handles multiple users in a single request, eliminating ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly advises when to use this tool (e.g., for multiple users) and warns against common misuse (e.g., 'never call this once per user'). It also implicitly suggests alternatives for single users or teams, providing clear context for tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It explains calendar expansion per user, exclusion of weekends and holidays, and the effect of the breakdown parameter. It also describes the return structure including sorting and zero-plans handling.
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?
The description is concise and well-structured. It starts with the purpose, then a critical usage note, followed by parameter details in a list format. Every sentence adds value without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 4 parameters, 0% schema coverage, no annotations, and an existing output schema, the description provides complete context. It explains parameters, behavior, and return structure (by_user and by_project totals). The output schema may cover return values, but the description adds clarity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description fully compensates. It explains usernames as Jira logins, date format as YYYY-MM-DD inclusive, breakdown as 'day' for detailed output, and the return structure. This adds significant meaning beyond the raw schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it retrieves planned allocations for a group of users in Tempo Planner, per user. It uses specific verbs ('get') and resource ('users plan'), and the context of sibling tools (e.g., get_user_plan for a single user) helps distinguish it.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly advises against calling per user: 'never call this once per user'. It explains that a single request covers all users in usernames for a date range. It could be improved by mentioning when to use the single-user alternative, but the guidance is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully carries the burden: it discloses that the tool creates a real worklog under the user's name, cannot be undone, and is the only write tool—providing essential behavioral context beyond the schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is relatively long but well-structured with a critical warning front-loaded, followed by clear arg definitions. Every sentence adds value, though the overall length could be slightly trimmed while retaining clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations and the tool's write nature, the description is complete: it covers purpose, usage rules, behavior, all parameters with examples, and mentions return value (even with an output schema). No gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Despite 0% schema coverage, the description thoroughly explains all parameters: 'issue_key' format, 'time_spent' Jira syntax with examples, 'started' formats and defaults, and 'comment' optionality. This fully compensates for the lack of schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it logs time on a Jira issue and uniquely identifies itself as the only write tool among siblings, effectively distinguishing it from read-only tools like 'get_user_worklog'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly instructs to call only on user's explicit request and warns against calling on its own initiative, providing clear when-to-use and when-not-to-use guidance. Siblings are implicitly contrasted as read-only.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully discloses behavioral traits: it writes a real issue, cannot be deleted, runs under the token owner's name, and returns the created issue's key/id/url. No contradictions with missing annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with headers and bullet points, front-loading the core purpose and usage guidelines. While slightly verbose, every sentence adds value, earning a high score.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (12 parameters, 2 required, output schema present), the description covers all parameters, usage guidelines, and return values comprehensively, leaving no gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description carries full burden. It explains each parameter in detail with examples, defaults, and relationships (e.g., parent for sub-task vs epic), far exceeding what the schema provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Create a Jira issue — epic, task, story or sub-task.' It uses a specific verb and resource, and distinguishes from siblings by listing the supported issue types, making the purpose unmistakable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says 'CALL THIS TOOL STRICTLY ON THE USER'S EXPLICIT REQUEST' and warns against creating issues on its own initiative. It also advises confirming a list of issues with the user, providing clear when-not and usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description fully discloses behavior: output includes per-worker entries with optional breakdowns (day, project, etc.), members with zero hours appear, and effects of include_subtasks, only_active, and exclude_absence parameters are detailed. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured with an Args section and parameter descriptions. Front-loaded purpose. Slightly verbose but every sentence adds value; no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 7 parameters (all explained), output schema exists (so return format not needed), and annotations absent, the description covers all necessary context: usage, behavior, parameter semantics, and edge cases (zero-hour members, absence handling). Complete for a complex tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, but description compensates thoroughly: explains team_id source, date format and inclusivity, breakdown options and their output structure, only_active rationale (team roster accumulation), and exclude_absence impact (vacation vs work). Adds significant meaning beyond bare schema types.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description specifies the exact resource (Tempo team worklog), action (get hours per member), and scope (date range, per worker). It distinguishes from siblings like get_user_worklog and get_users_worklog by focusing on team-level aggregation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states this tool covers the whole team in one call, recommending against per-user calls. Provides context by referencing the Tempo report and explaining how the team roster is handled. Implicitly suggests alternatives by contrasting with single-user tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description bears full burden. It discloses that types can be renamed/translated and that omitting project_key returns all types. Indicates read-only behavior and error handling.
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?
Description is concise with a clear intro, usage guidance, and an Args section. Every sentence provides essential information without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the output schema exists and the tool is simple (1 parameter), the description covers purpose, usage, and parameter semantics completely. No gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0% but description provides detailed meaning for the project_key parameter, explaining its purpose and effect. Adds significant value beyond schema structure.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists issue types for create_issue, with specific verb and resource. It distinguishes itself from sibling tools by focusing on issue types, not projects or users.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly advises to call this first when unsure about issue_type to avoid 400 errors. Explains when to use the optional project_key parameter and the consequence of omitting it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![jira-mcp MCP server](https://glama.ai/mcp/servers/nsleader/jira-mcp/badges/card.svg)](https://glama.ai/mcp/servers/nsleader/jira-mcp)

Score Badge

Copy to your README.md:

[![jira-mcp MCP server](https://glama.ai/mcp/servers/nsleader/jira-mcp/badges/score.svg)](https://glama.ai/mcp/servers/nsleader/jira-mcp)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/nsleader/jira-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server