Static source inference · medium confidence · detected: Logging
Deprecated protocol patterns detected
Summary
MCP Atlassian Server has 24 tools with consistent naming conventions (all verb_noun format: createIssue, updatePage, etc.) and basic input schemas. However, the server has critical gaps in description depth, schema completeness, parameter documentation, and error handling that prevent production use. Most tool descriptions are 1 - 2 sentences without context for LLM decision-making. Many parameters lack descriptions or type validation. Output schemas are undocumented, callers cannot know what fields to expect, forcing them to infer structure from trial-and-error. No evidence of error recovery guidance, parameter validation, or idempotency markers. Per-tool average across 24 tools is ~42, reflecting C-grade consistency issues affecting nearly all tools.
No documented output schemas for any tool. Callers cannot know what fields the tool returns. The test client (tool-test.ts) manually parses JSON responses and checks for properties like `.key`, `.success`, and `.text`, indicating output structure is runtime-discovered rather than spec'd. This forces LLMs to reason about response structure, increasing hallucination risk.
Document output schemas for all 24 tools. For each tool, specify the response structure (e.g., createIssue returns {key: string, id: string, self: string}). Include this in the tool description or a separate 'Output' section.
Expand tool descriptions to 80 - 150 characters with actionable context. Example: 'Create a new Jira issue in the specified project. Requires project key, summary, and issue type. Returns the new issue key and ID. Use createIssue before assigning it with assignIssue.' Current: 'Create a new Jira issue' (24 chars).
Add descriptions to all parameters. For string parameters, specify the expected format, valid values, or how to obtain them. Example: 'transitionId': 'The numeric ID of the target workflow transition (e.g., 11 for Start Progress). Call getTransitions(issueKey) first to list valid transition IDs.' Current: 'Transition ID' (12 chars).
Convert free-form string parameters to enums where valid values are known. Example: 'issueType' should be enum: [Task, Bug, Story, Epic, Sub-task, Subtask, Feature]. 'representation' in updateFooterComment should be enum: [storage, plain-text, view].
Add error handling guidance to tool descriptions. For destructive operations, state: 'DESTRUCTIVE: Cannot be undone. No confirmation step.' For write operations, hint: 'Returns error code if project not found or user lacks permissions. Retry is safe if the error is transient.'
Document idempotency contracts. For create operations, add to description: 'Idempotent if an idempotency key is provided (not yet exposed). Multiple calls with the same inputs will create duplicate records. Consider deduplication logic.'
Spec posture evidence
Inferred effective spec: <=2025-11-25.
Relies on Logging (deprecated) - log to stderr or use OpenTelemetry
Score history
Overall score trend
↑ 50 points across a rubric change (v1 → v2)
50/100
Scored
Grade
Overall
Spec posture
Rubric
2026-09-22
D
50
<=2025-11-25
v2
2026-03-09
F
0
-
v1
Create a new Jira filter
createIssuewriteauthsource verified65/100
Create a new Jira issue
createPagewriteauthsource verified65/100
Create a new Confluence page
createSprintwriteauthsource verified62/100
Create a new sprint on a Jira board
deleteFilterdestructiveauth50/100
Delete a Jira filter
deleteFooterCommentdestructiveauth50/100
Delete a footer comment in Confluence
deletePagedestructiveauthsource verified58/100
Delete a Confluence page
rankBacklogIssueswriteauth50/100
Rank/reorder issues in the backlog
removeGadgetFromDashboardwriteauth50/100
Remove a gadget from a Jira dashboard
startSprintwriteauth50/100
Start a sprint
transitionIssuewriteauthsource verified58/100
Change issue status/transition an issue to a different state
Tool descriptions are minimal (1 - 2 sentences, 20 - 50 chars). Examples: 'Create a new Jira issue' (24 chars), 'Update an existing Jira issue' (29 chars). These are too brief to guide LLM selection. Missing context: when to use, what happens on error, idempotency, prerequisites, post-conditions. Descriptions should be 50 - 200 chars with actionable detail.
Many parameters lack descriptions or have minimal ones. Example: 'transitionIssue' has parameters 'transitionId' (description: 'Transition ID') and 'comment' (description: 'Optional comment when transitioning'). No guidance on what a transition ID is, how to find it, or what values are valid. Parameter descriptions must explain the expected format, range, and how to obtain the value.
No error handling guidance in tool descriptions. Destructive operations (deleteFilter, deletePage, deleteFooterComment) give no hint of recovery steps or irreversibility. Write operations (createIssue, updatePage) provide no guidance on validation errors, retry eligibility, or side effects. LLMs need explicit error classification: retryable, user-fixable, or fatal.
Missing parameter descriptions. Parameters like 'gadgetKey' (in addGadgetToDashboard) and 'boardId' (in many tools) lack meaningful descriptions. The schema shows the type (string) but not what values are valid, how to discover valid IDs, or what format is expected.
No idempotency markers or guidance. Tools like createIssue and createPage will likely create duplicates if retried with the same inputs. No mention of whether operations are safe to retry or require deduplication logic. LLMs need explicit idempotency contracts.
Schema declarations for some parameters are incomplete. Parameters accept strings but lack enum, pattern, or format constraints. Example: 'issueType' (in createIssue) is a bare string, should be an enum (Task, Bug, Story, etc.). Free-form strings invite hallucinated values.
No pagination or result-limiting strategy documented. Tools like rankBacklogIssues and addIssuesToBacklog accept arrays but provide no guidance on maximum size, pagination, or truncation. Large arrays could exhaust context windows or hit API limits.
Tool names for operations on related resources risk confusion. Example: 'updateDashboard' vs 'addGadgetToDashboard', naming is clear, but 'removeGadgetFromDashboard' vs 'updateDashboard' could be conflated. Consistent naming is good here, but descriptions should clarify scope.
Add pagination/limit guidance to array parameters. Example: 'issueKeys' in addIssuesToBacklog should note: 'Array of issue keys (max 50 per call; use multiple calls for larger batches).'
Include chaining IDs in response schemas. If createIssue returns a key, and updateIssue accepts issueIdOrKey, ensure the response explicitly documents this. Add to output schema: 'key (string, use in updateIssue or transitionIssue).'
Add optional examples of valid parameter values in descriptions (not in the schema itself, which invites literal reuse). Example: 'sprintId: The numeric ID of the target sprint (e.g., 123). From getBoardSprints(boardId).'
Validate inputs early and return clear error messages. Example: Instead of letting the API fail on invalid issueType, check the enum on the server side and return: 'Invalid issueType: got "Feature", must be one of: Task, Bug, Story, Epic, Sub-task.'
Consider adding confirmation-step tools for destructive operations (deleteFilter, deletePage, deleteFooterComment). Or add a dry_run parameter that previews what will be deleted without executing.