Provides read-only tools for interacting with a self-hosted GitLab instance, including searching merge requests, retrieving MR details, commits, diffs, pipeline status, searching code, and fetching files.
Provides read-only tools for interacting with Jira Server/Data Center, including fetching issues, subtasks, linked issues, comments, attachments, epics, sprints, and performing JQL searches.
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@devflow-mcp get ticket bundle for PROJ-123"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
Local, read-only MCP server that securely serves Jira (Server/Data Center) data to Claude Code — without ever exposing your PAT/token to the model. (GitLab tools + the /devflow skill land in later phases; see the plan.)
Plan:
plans/260625-1353-jira-ai-dev-mcp/
The token lives only inside this server's HTTP client (read from an env var). Claude calls tools like jira_get_ticket_bundle("PROJ-123") and gets back trimmed JSON — it never sees the credential, and the credential is never a tool argument.
Related MCP server: jira-mcp-server
Python ≥ 3.10
A Jira Server/DC Personal Access Token (Bearer). Profile → Personal Access Tokens.
cd devflow-mcp
python3 -m venv .venv
source .venv/bin/activate
pip install -e . # or: pip install -e ".[dev]" for tests
cp .env.example .env # then edit JIRA_BASE_URL + JIRA_PAT.env (gitignored) for local runs:
JIRA_BASE_URL=https://jira.your-company.com
JIRA_PAT=xxxxxxxxxxxxfastmcp dev server.py
# open the Inspector URL, call jira_get_ticket_bundle with a real issue keyFirst, call jira_get_fields once and note the custom field IDs for Sprint / Epic Link / Story Points — needed in later phases.
Add to your project .mcp.json (commit this — it has NO secrets, only ${VAR} refs):
{
"mcpServers": {
"devflow": {
"command": "/ABS/PATH/devflow-mcp/.venv/bin/python",
"args": ["/ABS/PATH/devflow-mcp/server.py"],
"env": {
"JIRA_BASE_URL": "${JIRA_BASE_URL}",
"JIRA_PAT": "${JIRA_PAT}",
"GITLAB_URL": "${GITLAB_URL}",
"GITLAB_TOKEN": "${GITLAB_TOKEN}"
}
}
}
}Put the real values in your shell (~/.zshrc). GitLab is optional — omit it and GitLab tools self-disable:
export JIRA_BASE_URL="https://jira.your-company.com"
export JIRA_PAT="xxxxxxxxxxxx"
export GITLAB_URL="https://gitlab.your-company.com" # self-hosted; /api/v4 appended automatically
export GITLAB_TOKEN="glpat-xxxxx" # scopes: read_api, read_repositoryRestart Claude Code, then the tools appear.
Jira core
Tool | Purpose |
| primary: issue + subtasks + links + comments + attachment metadata in one call |
| single issue, trimmed |
| recent comments |
| subtasks / linked issues |
| JQL search (paginated, capped) |
| resolve custom field IDs (setup) |
Jira agile — jira_get_epic, jira_get_epic_issues, jira_get_sprint, jira_get_sprint_issues
Jira attachments (image analysis) — jira_get_attachments(key), jira_download_attachment(key, attachment_id) → downloads to a local path (token hidden) so Claude can read mockups/screenshots with vision.
GitLab (self-hosted, optional) — gitlab_search_mrs(ticket_key), gitlab_get_mr, gitlab_get_mr_commits, gitlab_get_commits, gitlab_get_commit_diff, gitlab_get_pipeline_status, gitlab_search_code, gitlab_get_file.
Secrets are read from env only; never accepted as args, never returned, masked in errors.
Read-only: no write/transition/comment endpoints are implemented.
JIRA_VERIFY_SSL=false only for trusted internal self-signed certs.
Exits "Missing required environment variable" → set JIRA_BASE_URL / JIRA_PAT.
401/403 → check PAT validity + project permissions.
SSL error on internal host → set JIRA_VERIFY_SSL=false (trusted hosts only).
Get a commit's diff (read-only). Truncated for token efficiency.
| Name | Required | Description | Default |
|---|---|---|---|
| sha | Yes | commit SHA. | |
| project | Yes | numeric ID or 'group/repo' path. |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses that the tool is read-only and that the output is truncated for token efficiency, which are key behavioral traits. However, it could add details about size limits or 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with two sentences that front-load essential information. Every word adds value with no redundancy.
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 that the tool has an output schema, the description does not need to explain return values. It covers the key contextual points (read-only, truncated), but could briefly mention the diff format or size constraints for completeness.
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?
The schema already provides 100% coverage with descriptions for both 'sha' and 'project'. The description adds no additional meaning beyond what the schema provides, so baseline 3 is appropriate.
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 clearly states 'Get a commit's diff' with a specific verb and resource, and distinguishes itself from sibling tools like gitlab_get_commits. It also notes the read-only nature and truncation for token efficiency.
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?
While the description implies usage for retrieving a commit diff and notes truncation, it does not explicitly state when to use this tool over alternatives like gitlab_get_commits or provide exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List recent commits for a project branch/ref (read-only).
| Name | Required | Description | Default |
|---|---|---|---|
| ref | No | ||
| limit | No | ||
| project | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided. Description only states 'read-only,' which hints at no side effects, but lacks details on pagination, rate limits, authentication requirements, or default behavior when ref is null. The full burden is on the description, which is insufficient for 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence that is direct and efficient. No superfluous words. Every word adds value.
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 3 parameters and an output schema, the description is minimal. It does not mention ordering (e.g., most recent first), commit details returned, or how to distinguish from gitlab_get_mr_commits. Output schema exists, but behavioral context is lacking.
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 describes 3 parameters with 0% coverage (no descriptions). Description adds meaning by mentioning 'project branch/ref' for the 'ref' parameter, but does not explain 'project' (full path or ID?), that 'limit' controls maximum commits, or default behavior when ref is null. With no schema descriptions, description should compensate more.
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?
Description clearly states the tool lists recent commits for a project branch/ref and is read-only. Verb 'list' and resource 'commits' are specific, and the scope is defined. It distinguishes from sibling tools like gitlab_get_commit_diff or gitlab_get_mr_commits.
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?
Description implies when to use (to list recent commits) but provides no guidance on when not to use, e.g., when needing commit diffs or merge request commits. No explicit alternatives or exclusions are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read a repo file's content (read-only). Truncated for token efficiency.
| Name | Required | Description | Default |
|---|---|---|---|
| ref | No | branch/tag/SHA (default 'main'). | main |
| project | Yes | numeric ID or 'group/repo' path. | |
| file_path | Yes | path within the repo, e.g. 'src/utils/auth.js'. |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses read-only nature and truncation for token efficiency. No annotations exist, so description carries the burden; these are valuable behavioral traits beyond a simple schema.
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?
Extremely concise: two sentences, front-loaded with purpose, no wasted words.
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 existence of an output schema and simple tool nature, description is mostly complete. Truncation note adds necessary context.
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 coverage is 100%, so parameters are fully described in the schema. The description adds no additional parameter meaning.
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 clearly states 'Read a repo file's content (read-only)', specifying the action and resource. It distinguishes from siblings like gitlab_get_commit_diff (diffs) and gitlab_search_code (searching).
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 explicit when-to-use or when-not-to-use guidance. Usage is implied by the purpose, but alternatives are not mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get a single merge request (read-only).
| Name | Required | Description | Default |
|---|---|---|---|
| mr_iid | Yes | ||
| project | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, leaving the description as the sole source of behavioral info. It mentions 'read-only' but does not disclose error handling, permissions, or response size. Minimal disclosure.
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 a single, focused sentence that front-loads the action and resource. Every word earns its place with no redundancy.
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?
For a simple read tool with an output schema, the description is adequate but incomplete. It fails to clarify parameter semantics, which is a notable gap. Without annotations, more context would be beneficial.
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 coverage is 0% and the description does not explain any parameters. The agent is left to infer that mr_iid is an integer ID and project is a string, but their specific meaning (e.g., merge request IID, project path) is missing.
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 clearly states the verb 'Get', resource 'single merge request', and adds 'read-only' to clarify behavior. It distinguishes from siblings like gitlab_get_mr_commits by specifying a single merge request.
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 description says 'read-only' which hints at usage, but gives no explicit when-to-use or when-not-to-use, nor mentions alternatives among siblings. It is clear in intent but lacks guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List commits in a merge request (read-only).
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| mr_iid | Yes | ||
| project | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description explicitly marks the operation as 'read-only', which is a key behavioral trait indicating safety. However, with no annotations, the description carries the full burden. It does not disclose that the 'limit' parameter defaults to 50, how results are ordered, or what happens with empty results. It adds value but remains minimal.
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 a single sentence of 6 words, containing no redundant information. It is perfectly concise and front-loaded with the operation type.
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?
Although the tool has a complex output schema (context indicates it exists), the description does not mention pagination, ordering, fields returned, or how the 'limit' parameter works. For a list tool with multiple parameters, the description insufficiently prepares the agent for proper invocation.
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?
The input schema has 0% description coverage, meaning no parameter descriptions exist in the schema. The tool description does not elaborate on any parameters, leaving the agent to infer from names alone. While 'project' and 'mr_iid' are somewhat intuitive, 'limit' is ambiguous without context (e.g., maximum number of commits).
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 clearly states the verb 'List' and the resource 'commits in a merge request', specifying the action and scope. It distinguishes itself from sibling tools like 'gitlab_get_commits' (which likely lists all commits in a project) and 'gitlab_get_commit_diff' (which gets diff of a specific commit).
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 description does not provide any guidance on when to use this tool versus alternatives like 'gitlab_get_commits' or 'gitlab_search_code'. There are no use case examples, exclusions, or prerequisites mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get latest pipeline status for a branch/ref or a merge request (read-only).
Provide either ref (branch) or mr_iid.
| Name | Required | Description | Default |
|---|---|---|---|
| ref | No | ||
| mr_iid | No | ||
| project | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description declares the tool is read-only, which is a key behavioral trait. However, it does not specify what happens if both ref and mr_iid are omitted (schema allows both null), nor any error conditions, rate limits, or authentication requirements. Since no annotations are provided, the description carries full burden and lacks these details.
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 consists of two concise sentences with no filler or redundant information. The first sentence states the purpose and read-only nature; the second gives critical usage guidance. Every word adds value.
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?
For a tool with 3 parameters and no param descriptions, the description covers ref and mr_iid well but leaves ambiguity about the project parameter (required but not explained) and the behavior when both optional params are missing. While the output schema exists, the description could be more complete regarding edge cases.
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?
With 0% schema description coverage, the description clarifies that ref is a branch and mr_iid is a merge request IID, and that they are mutually exclusive. It does not elaborate on the project parameter, but the naming is sufficiently self-explanatory. This adds meaningful context beyond the raw schema types.
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 specifies the exact action ('Get latest pipeline status') and resource ('for a branch/ref or a merge request'), clearly distinguishing it from sibling tools like gitlab_get_commits or gitlab_get_mr. It also explicitly states it is read-only, further clarifying its safe nature.
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 description directly instructs the agent to 'Provide either ref (branch) or mr_iid', making the parameter choice clear. While it does not explicitly mention when not to use this tool versus alternatives, the standalone purpose of fetching pipeline status is sufficiently distinct from sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search code (blobs) across GitLab (read-only). Degrades gracefully.
Use this only for repos NOT checked out locally; for local repos prefer Claude's native Grep/Glob. Requires Advanced Search on the instance.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| query | Yes | ||
| project | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses the tool is read-only and states it 'degrades gracefully', implying error handling. It also highlights the requirement for Advanced Search, which is critical behavior. However, it could mention what happens when the requirement is not met or provide more detail on rate limits or pagination.
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 extremely concise at three sentences, with the most important information first. Every sentence adds value: purpose, usage guidance, and a critical requirement. There is no redundancy or fluff.
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?
While the description covers purpose, usage, and key behavior, it omits parameter explanations and does not describe the output schema (which exists). The 'degrades gracefully' phrase is vague. Given the tool has 3 parameters and an output schema, the description could be more thorough without being long.
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?
The input schema has 0% coverage (no parameter descriptions). The description does not explain the parameters: query, limit, and project. It only mentions that it searches code, leaving the agent to infer parameter meanings from names. This is insufficient for a tool with three parameters, especially without schema descriptions.
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 explicitly states the verb 'Search', the resource 'code (blobs)', and the scope 'across GitLab'. It clearly identifies the tool as read-only and distinguishes it from siblings by specifying it's for repos not checked out locally, contrasting with other GitLab tools that handle specific files or diffs.
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 description provides clear guidance on when to use the tool (repos not checked out locally) and when to prefer alternatives (Claude's native Grep/Glob for local repos). It also mentions a prerequisite ('Requires Advanced Search on the instance'), helping the agent avoid failures.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Find merge requests referencing a ticket key (read-only, heuristic).
Searches MR title + description for the key. Linkage is a HEURISTIC — results are candidates, not guaranteed matches.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Max MRs to return. | |
| project | No | Optional numeric ID or 'group/repo' path to scope the search. | |
| ticket_key | Yes | e.g. 'PROJ-123'. |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully carries the burden. It explicitly states that the tool is read-only and that results are heuristic candidates, not guaranteed matches. This is a strong behavioral disclosure that manages expectations, though it could mention pagination or limit behavior.
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 very concise: two sentences with no wasted words. The key information (read-only, heuristic, search scope) is front-loaded, making it easy for the agent to quickly understand the tool's purpose.
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 that an output schema exists (though not provided), the description need not detail return values. It covers purpose, scope, and caveats. Missing context includes what happens when no results are found or if the ticket key format is invalid, but these are minor omissions.
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 coverage is 100%, so baseline is 3. The description adds minimal parameter-specific value beyond what the schema already provides (e.g., ticket_key example 'PROJ-123'). No new constraints or formatting details are introduced.
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 clearly states the verb ('find') and resource ('merge references') with a specific search scope (ticket key in MR title + description). It distinguishes from siblings like gitlab_get_mr (retrieves a specific MR) and gitlab_search_code (searches code) by focusing on ticket-linking heuristic.
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 description clarifies that the tool is read-only and heuristic, implying it should be used when exact linkage is not required. However, it does not explicitly exclude cases where a known MR ID is available or suggest gitlab_get_mr as an alternative, which would strengthen the guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Download one Jira attachment to a LOCAL file and return its path (read-only).
The download uses the server's authenticated client (token stays hidden).
Claude can then read the returned path with vision, or pass it to the
ai-multimodal skill, to analyze an image/mockup attached to the task.
| Name | Required | Description | Default |
|---|---|---|---|
| key | Yes | Issue key, e.g. 'PROJ-123'. | |
| attachment_id | Yes | The attachment id (from jira_get_attachments). |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description discloses the read-only nature, use of server's authenticated client, and that the token remains hidden. It also indicates the return type is a file path. Missing details on error handling or size limits, but the key security aspect is well covered.
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 concise with two sentences, front-loading the main action and providing additional context efficiently. Every sentence adds value without redundancy.
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 presence of an output schema and well-described parameters, the description covers the essential use case and outcome. It could be more complete by mentioning potential errors or file type support, but it is sufficient for typical use.
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 coverage is 100% with clear parameter descriptions. The description adds context by noting that attachment_id comes from jira_get_attachments, which helps users understand the parameter's origin. This enhances semantic meaning beyond the schema alone.
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 clearly states the verb 'Download' and resource 'Jira attachment', specifying it stores to a local file and returns the path. It is distinct from sibling tools like jira_get_attachments which list attachments.
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 description implies usage after obtaining attachment IDs from jira_get_attachments and suggests using the result for analysis with vision or ai-multimodal. However, it does not explicitly state when not to use this tool or mention alternatives for different scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List attachment metadata on a Jira issue (read-only, no download).
Use this to see whether a task has images/mockups worth analyzing. Download a specific one with jira_download_attachment.
| Name | Required | Description | Default |
|---|---|---|---|
| key | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses read-only nature and no download, but with no annotations, could mention more about permissions or limits.
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?
Two sentences, front-loaded with purpose, no wasted words.
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?
Simple tool with one param and output schema; description covers purpose and usage adequately.
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?
With 0% schema coverage, description does not explain the 'key' parameter, leaving the agent to infer from context.
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?
Clearly states 'List attachment metadata on a Jira issue' with verb and resource, and distinguishes from sibling jira_download_attachment.
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?
Explicitly says when to use ('to see whether a task has images/mockups worth analyzing') and directs to alternative for download.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fetch comments on a Jira issue (read-only). Returns the most recent limit.
| Name | Required | Description | Default |
|---|---|---|---|
| key | Yes | Issue key, e.g. 'PROJ-123'. | |
| limit | No | Max comments to return (newest kept). Default 20. |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses that the tool is read-only and returns only the most recent comments up to the limit. This is sufficient given the tool's simplicity, but it could further mention ordering direction or error behavior. With no annotations, the description carries the burden and performs adequately.
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?
Two sentences, no wasted words. Clearly communicates the purpose and a key behavioral detail. Extremely concise.
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?
For a simple read-only tool with output schema exists, the description covers the core functionality. It could mention the ordering or pagination but is mostly complete. The presence of an output schema reduces the need to explain return values.
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 100%, so the baseline is 3. The description adds minimal context beyond the schema: it mentions 'most recent' which matches the schema's 'newest kept' for limit. No additional meaning is added for the key parameter.
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 clearly states the verb 'Fetch' and the resource 'comments on a Jira issue', and distinguishes it from sibling Jira tools by specifying the action on comments. It is specific and unambiguous.
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 description implies usage when needing comments for an issue but does not provide explicit guidance on when to use it versus alternatives (e.g., when to use jira_get_issue instead). No when-not-to-use or alternative naming is given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get a Jira epic by key/id (read-only).
| Name | Required | Description | Default |
|---|---|---|---|
| epic_key | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. It declares the operation is 'read-only', which is a key behavioral trait. However, it does not disclose outcomes for missing keys, authentication needs, or other potential behaviors beyond the basic nature.
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 a single concise sentence with no unnecessary words. It is front-loaded with the essential information, achieving high efficiency.
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?
For a simple tool with one parameter and an output schema, the description is nearly complete. It covers the core functionality. Minor omissions include no guidance on error cases or required permissions, but overall it suffices given low complexity.
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 add meaning. The phrase 'by key/id' clarifies that epic_key accepts either a key or an ID, which adds value beyond the schema's 'string' type. However, it does not specify the exact format or provide examples.
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 clearly states the verb 'Get' and the resource 'Jira epic', and specifies retrieval by key/id. It also includes 'read-only' to distinguish from modification tools, aligning with siblings like jira_get_issue and jira_get_epic_issues.
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 description implies usage when needing epic details, but does not explicitly contrast with sibling tools like jira_get_epic_issues or provide when-not-to-use guidance. It lacks explicit alternatives or context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List issues belonging to an epic (read-only).
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| epic_key | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description carries full burden. It adds only a read-only note but fails to disclose pagination, ordering, rate limits, or other behavioral traits beyond what is implied by a list operation.
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 a single sentence, concise and front-loaded with the main action. However, it could be structured to include parameter hints without sacrificing brevity.
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?
Despite having an output schema, the description does not mention return format, what properties are returned, or how limit affects results. The lack of parameter descriptions makes the tool under-specified for an AI agent.
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%, yet the description adds no meaning to the parameters (epic_key, limit). It does not explain what epic_key refers to or that limit controls result count, leaving the agent to infer from names alone.
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 clearly states the verb 'List', the resource 'issues belonging to an epic', and indicates the tool is read-only. It distinguishes from siblings like jira_get_epic and jira_get_issue which handle single resources.
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 explicit guidance on when to use this tool vs alternatives like jira_search or jira_get_issue. The description does not provide context for appropriate usage scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List Jira field metadata to resolve custom field IDs (read-only).
Run once per instance during setup to discover IDs for Sprint, Epic Link, Story Points, etc. (these differ per Jira instance).
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description explicitly states 'read-only', which is helpful given no annotations. However, it lacks details on authentication, rate limits, or output behavior beyond the schema. It meets basic transparency but does not fully compensate for absent annotations.
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?
Two concise sentences with no wasted words. The purpose is front-loaded, and every sentence adds value.
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 no parameters and an existing output schema, the description is completely adequate. It explains why, when, and what the tool does, requiring no additional context.
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?
With zero parameters and 100% schema coverage, the description adds meaning by explaining the tool's purpose and use case for resolving custom field IDs. This exceeds the baseline of 3 for high coverage.
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 clearly states it lists Jira field metadata to resolve custom field IDs, specifies it is read-only, and distinguishes itself from sibling tools like jira_get_issue by focusing on metadata discovery.
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 description advises to run once per instance during setup and provides example use cases (Sprint, Epic Link, Story Points), clearly implying when to use it. However, it does not explicitly exclude other scenarios or mention alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fetch a single Jira issue (read-only).
| Name | Required | Description | Default |
|---|---|---|---|
| key | Yes | Issue key, e.g. 'PROJ-123'. | |
| fields | No | Optional comma-separated Jira field list. Defaults to a token-efficient set (summary, status, assignee, description, ...). |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description labels the tool as 'read-only', which is a key behavioral trait. However, no other behaviors are disclosed (e.g., error handling, rate limits, or authentication needs). Given the tool's simplicity, the single trait is adequate but not comprehensive.
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 a single sentence that conveys the essential action and resource. While very concise, it could be slightly expanded without losing efficiency. It earns a high score for being front-loaded and free of fluff.
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 low complexity (1 required parameter, 2 total, with an output schema), the description covers the basic function. However, it lacks usage guidelines and does not leverage the existence of the output schema to provide additional context. It is minimally complete.
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?
The input schema already provides full descriptions for both parameters (key and fields) with 100% coverage. The description adds no additional parameter semantics, so it meets but does not exceed the baseline.
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 clearly states it fetches a single Jira issue and notes it is read-only. While it identifies the resource and action, it does not differentiate from sibling tools like jira_get_epic, but the specificity of 'single Jira issue' is sufficient.
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 guidance on when to use this tool versus alternatives. It does not mention when to prefer this over jira_search or jira_get_epic_issues, nor does it specify prerequisites or context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List issues linked to a Jira issue (read-only), with relation + direction.
| Name | Required | Description | Default |
|---|---|---|---|
| key | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description bears full burden. Declares 'read-only', which is critical. Mentions 'relation + direction' as return data. Lacks details on required permissions or 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single, well-structured sentence with no redundancy. All words add value.
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 a simple tool with output schema, the description covers core behavior and data. Missing error handling or edge cases, but acceptable for a read-only list.
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 coverage is 0%, so description must clarify the parameter. It implicitly identifies 'key' as the Jira issue, but doesn't specify format (e.g., 'PROJ-123'). Partially helpful but incomplete.
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?
Description clearly states verb 'list', resource 'issues linked to a Jira issue', and adds 'read-only' and 'relation + direction' for specificity. Differentiates from siblings like 'jira_get_issue' or 'jira_get_subtasks'.
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?
Implies usage for listing linked issues with relation data. No explicit exclusions or alternatives, but context clear given sibling list.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get a sprint by id (read-only).
| Name | Required | Description | Default |
|---|---|---|---|
| sprint_id | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must carry the full burden of behavioral disclosure. It correctly identifies the operation as 'read-only', implying no side effects. However, it fails to mention what happens if the sprint ID is invalid, whether authentication is required, or any rate limit considerations. For a simple get operation, the transparency is adequate but not 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 a single, well-structured sentence that conveys the essential information without any fluff. It is front-loaded with the action and resource, and the parenthetical 'read-only' adds a key behavioral hint. Every element earns its place.
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 simplicity (one parameter, output schema exists), the description covers the core functionality. However, it lacks context about where sprint IDs come from (e.g., from jira_search or jira_get_sprints), and does not mention the output schema or any error states. The completeness is acceptable for a minimal read operation but could be improved with a line about expected input or usage.
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?
The description does not add meaning to the parameter beyond the schema. While the schema declares 'sprint_id' as a required integer, the description merely says 'by id', which is generic. Since schema description coverage is 0%, the description should compensate, but it does not provide details like the source or format of the sprint ID. The parameter name is self-explanatory, so the deficit is small but present.
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 clearly states the verb 'Get', the resource 'sprint', and the method 'by id', making it unambiguous. It also labels the operation as 'read-only', which aligns with the tool's nature. Among siblings like jira_get_issue or jira_get_epic, this description sufficiently distinguishes the tool's purpose.
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 guidance is provided on when to use this tool versus alternatives (e.g., jira_get_sprint_issues). The description does not mention prerequisites, such as needing a valid sprint ID, nor does it indicate scenarios where it should be avoided. The 'read-only' hint is the only contextual clue.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List issues in a sprint (read-only).
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| sprint_id | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description notes the tool is 'read-only', which is a key behavioral trait. However, with no annotations provided, it should disclose more (e.g., error conditions, rate limits). The brief statement partially compensates but is insufficient for 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short and front-loaded with the core purpose. However, it omits critical details, so conciseness comes at the cost of completeness. Still, it earns points for efficiency.
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 presence of an output schema (not shown) and lack of annotations, the description is incomplete. It fails to explain parameter semantics, return format, or any edge cases, leaving significant gaps for an agent to fill.
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%, and the description does not explain the parameters (sprint_id, limit). The agent receives no guidance on parameter meaning or usage beyond the schema's technical definitions.
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 clearly states the action ('List issues') and the resource ('in a sprint'), with a parenthetical '(read-only)' that adds clarity. It distinguishes this tool from siblings like 'jira_get_issue' (single issue) and 'jira_get_sprint' (sprint details).
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 usage guidelines are provided. The description does not indicate when to use this tool versus alternatives such as 'jira_search' or 'jira_get_issue', nor does it mention prerequisites or limitations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List subtasks of a Jira issue (read-only).
| Name | Required | Description | Default |
|---|---|---|---|
| key | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations were provided, so the description carries the full burden. It discloses that the tool is read-only, which is a key behavioral trait. However, it does not mention other behaviors like pagination, result structure, or error conditions beyond what the input schema suggests.
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 a single, short sentence that conveys the core purpose immediately. It is front-loaded and concise, though it could benefit from a tiny bit more context without losing brevity.
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 low complexity (single parameter, output schema present), the description is minimally sufficient. It tells the agent what the tool does and its safety profile. However, it omits explanation of the parameter and any usage context, making it slightly lacking for a new agent.
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?
The schema coverage is 0%, yet the description adds no additional meaning for the 'key' parameter beyond its name. It does not explain what the key represents (e.g., Jira issue key) or any constraints (e.g., format, required).
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 clearly states the action (List) and the resource (subtasks of a Jira issue), and explicitly marks it as read-only. It distinguishes from sibling tools like jira_get_issue or jira_get_epic_issues by focusing specifically on subtasks.
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 description implies usage for listing subtasks of a given issue, but does not provide explicit guidance on when to use this tool versus alternatives (e.g., jira_get_issue might return subtasks in its fields). No exclusions or conditions are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
One-call ticket context for analysis (read-only): the PRIMARY tool for /jira-dev.
Returns the issue + subtasks + linked issues + recent comments in a single token-efficient payload, avoiding multiple round-trips.
| Name | Required | Description | Default |
|---|---|---|---|
| key | Yes | Issue key, e.g. 'PROJ-123'. |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, but the description states the tool is read-only and returns a token-efficient payload. This adequately discloses the lack of side effects and efficiency benefits, though more details on rate limits or permissions are absent.
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 two sentences, front-loaded with the core purpose and key benefit. Every sentence adds value without unnecessary words.
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?
The description covers the main return content (issue, subtasks, linked issues, comments) and notes an output schema exists. It does not detail error cases or size limits, but for a retrieval tool with an output schema, this is 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?
The input schema has 100% description coverage for the single 'key' parameter. The description does not add additional meaning beyond what the schema provides, so baseline score of 3 is appropriate.
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 clearly states the tool returns a bundle of issue, subtasks, linked issues, and comments in a single call. It explicitly says it is the PRIMARY tool for /jira-dev and is read-only, distinguishing it from sibling tools that retrieve individual components.
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 description strongly implies this tool should be used for one-call ticket context, avoiding multiple round-trips, and is primary for analysis. It lacks explicit when-not-to-use scenarios but provides clear context for when to prefer it over alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List MY tasks: assigned to me, in active statuses (default: To Do, Doing).
This is the default local-dev working set — call with no key to see what to work on. Override statuses via env JIRA_ACTIVE_STATUSES.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Max tasks to return. | |
| extra_jql | No | Optional extra JQL ANDed in, e.g. 'project = PROJ'. |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description carries the burden. It discloses that the tool returns tasks assigned to the current user, with active statuses (default To Do, Doing), and mentions the ability to override via environment variable. This is transparent about filtering behavior.
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 two sentences plus a short note, all front-loaded with the main purpose. Every sentence adds value with no wasted words.
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?
For a simple list tool with output schema and 2 parameters, the description is complete: it explains purpose, default behavior, customization, and usage hint. No need for return value explanation since output schema exists.
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 coverage is 100% with descriptions for both parameters. The description adds context beyond the schema, such as 'call with no key' and the environment variable override for statuses, which is not in the schema.
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 clearly states the tool lists tasks assigned to the user in active statuses, with specific defaults. It distinguishes itself from siblings like jira_search by emphasizing 'MY tasks' and being the default local-dev working set.
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 description tells when to use it (call with no key to see what to work on) and hints at customization via environment variable. It does not explicitly state when not to use it or compare to alternatives, but the context is sufficient for typical use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search Jira issues by JQL (read-only), with offset pagination.
| Name | Required | Description | Default |
|---|---|---|---|
| jql | Yes | JQL query, e.g. 'project = PROJ AND status = "In Progress"'. | |
| limit | No | Max issues to return (capped at 50). | |
| fields | No | Optional comma-separated field list. |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It correctly notes 'read-only' and 'offset pagination', but does not disclose error behavior, rate limits, or authorization needs.
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?
A single, efficient sentence that conveys the core functionality (search, JQL, read-only, pagination) with zero waste.
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 a full output schema and 100% parameter coverage in the schema, the description adds necessary context (read-only, pagination). It is sufficient for a straightforward read tool.
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 100%, so the schema already documents all three parameters. The description adds no extra parameter meaning beyond the schema, achieving baseline.
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 clearly states the verb 'Search', the resource 'Jira issues', and the method 'by JQL', distinguishing it from siblings like jira_get_issue (single issue) and jira_get_epic_issues.
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 description implies read-only usage but provides no explicit guidance on when to use this tool versus alternatives like jira_get_issue or jira_get_epic_issues. No when-not or exclusion criteria given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Each tool has a unique, well-defined purpose. GitLab and Jira tools are cleanly separated by prefixes, and within each domain, tools target distinct resources (e.g., commits, MRs, pipelines, issues, attachments) with no functional overlap.
All tools follow a consistent `domain_verb_noun` pattern in snake_case. GitLab tools start with `gitlab_` and Jira tools with `jira_`, and verbs like `get_`, `search_`, `download_` are used uniformly.
With 22 tools, the server covers two distinct domains (GitLab and Jira) comprehensively. While slightly above the typical 3-15 range, each tool addresses a specific need for developer workflows, justifying the count.
The tools comprehensively cover read operations for GitLab (commits, files, MRs, pipelines, code search) and Jira (issues, epics, sprints, attachments, comments). However, write operations (creating/updating MRs or issues) are absent, leaving a gap for lifecycle management.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
An MCP server that provides read access to your cloud storage providers, bank accounts and more.
MCP server unifying ERPs, CRMs, APIs and knowledge base for Claude, ChatGPT and Gemini.
A MCP server built for developers enabling Git based project management with project and personal…
An MCP server that provides an API to LLMs to manage their JumpCloud resources.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/vulq-cmd/jira-dev-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
