The server provides 6 tools with clear verb_noun naming conventions (search_issues, read_issue, list_projects, etc.). All tools have non-empty descriptions and declared input schemas with type information. However, there are notable gaps in parameter documentation, output schema clarity, and error handling patterns. The Cyrillic validation logic is thorough but unconventional. Most tool outputs are returned as JSON strings rather than structured objects, making it harder for LLMs to extract and chain results. The server demonstrates solid foundational quality (descriptions present, schemas visible, naming clear) but lacks polish in parameter-level guidance and output structure documentation.
Tools (6)
create_issuewriteauthsource verified74/100
Create a new Jira issue. Summary and description MUST be in English.
list_projectsread onlyauthsource verified73/100
List all Jira projects you have access to.
my_open_issuesread onlyauthsource verified72/100
Get all unresolved issues assigned to you, sorted by update time.
read_issueread onlyauthsource verified73/100
Get details of a specific Jira issue.
search_issuesread onlyauthsource verified78/100
Search Jira issues using JQL.
update_issuewriteauthsource verified73/100
Edit an existing issue's summary, description or labels. English only.
Output schemas not documented. All tools return JSON strings, but LLM must infer structure by reading code. No explicit schema definitions for response fields, types, or nesting.
Parameter descriptions include example values (TSP-123, TSP, TSP-619) that LLMs frequently reuse verbatim in real calls instead of adapting to context.
issue_type parameter in create_issue lists 'Common values: Story, Bug, Task, Sub-task' as free-form text rather than a formal enum. LLMs may hallucinate invalid issue types (e.g. 'Feature Request', 'Epic', 'Spike') not supported by the Jira instance.
create_issue
Recommendations
Document output schemas for every tool. For search_issues and my_open_issues, define: { total: int, issues: [{ key: string, summary: string, status: string, priority: string, type: string, assignee: string | null, reporter: string, updated: ISO8601, created: ISO8601 }] }. For read_issue, document all returned fields. For create_issue and update_issue, document the returned issue object structure.
Replace example values in parameter descriptions with formal constraints. Instead of 'e.g. TSP-123', use: 'Jira issue key in format [PROJECT_KEY]-[NUMBER], e.g. format matching ^[A-Z]+\d+$'. Store examples in a separate 'examples' section if needed.
Convert issue_type to an enum. In create_issue, change description from text list to: { "type": "string", "enum": ["Story", "Bug", "Task", "Sub-task"], "description": "..." }. If instance-specific types are needed, add a list_issue_types tool.
Expand tool descriptions to 100-200 characters and include usage guidance. For search_issues: 'Search Jira issues using JQL. Call this for complex queries or to find multiple issues. For the current user\'s open issues, use my_open_issues instead. Returns a list of matching issues with key, summary, status, and assignment details.' For list_projects: 'List all Jira projects accessible to the authenticated user. Call this first to discover project keys before creating issues. Use returned project keys in create_issue.'
Add per-tool error recovery guidance. Wrap tool calls with try-except and provide hints: If HTTPError 404 on read_issue, suggest 'Issue not found; try search_issues to find the correct key.' If ValueError on create_issue due to Cyrillic, already present but could link to allow_cyrillic flag more prominently.
No error handling guidance. Tools raise ValueError or httpx.HTTPError, but responses do not provide recovery hints (e.g. 'User not found; try search_users() first'). LLM gets exception traces instead of actionable instructions.
No pagination for list_projects (hardcoded maxResults=50). If a Jira instance has >50 projects, only the first 50 are discoverable. Tool description doesn't mention this limit or offer next_cursor/offset pattern.
my_open_issues() internally delegates to search_issues() with a hardcoded JQL, but this composition is not documented. LLM cannot see that it returns the same structure as search_issues or that the JQL is fixed.
Tool descriptions are below production baseline. Average is ~65 chars; baseline is 194 chars. Descriptions like 'List all Jira projects you have access to.' (40 chars) lack context on discovery purpose or when to call this vs. search_issues.
No tool differentiation guidance. The server offers both search_issues and my_open_issues, which overlap significantly. LLM has no documented guidance on when to call one vs. the other, risking redundant calls.
search_issuesmy_open_issues
Document parameter interdependencies. In create_issue, clarify: 'parent_key is required only when issue_type=\'Sub-task\'. For other issue types, parent_key is optional and depends on project configuration.' In update_issue, clarify: 'All fields (summary, description, labels) are optional; omit to leave unchanged. At least one field must be provided.'
Add pagination to list_projects. Change maxResults from hardcoded 50 to a parameter (e.g. limit: int, default=20, max=100) and add offset or startAt. Document: 'If total > limit, paginate with offset parameter to retrieve all projects.'
Clarify tool composition. Add note in my_open_issues description: 'Equivalent to calling search_issues with JQL=\'assignee = currentUser() AND resolution = Unresolved ORDER BY updated DESC\'. Useful shorthand for the most common agent query. Returns same structure as search_issues.'
Add a tool differentiation matrix in server documentation or as a resource. E.g. a table showing when to use search_issues (complex JQL), read_issue (single issue details), my_open_issues (current user shortcut).
Validate and document constraints for max_results parameters. search_issues and my_open_issues cap at 20 and 30 respectively, but tool definitions should state: 'max_results: 1 - 100 (capped by Jira API)' to prevent LLM from requesting absurd limits.