Static source inference · medium confidence · detected: Logging
Deprecated protocol patterns detected
Summary
This MCP server has critical definition quality gaps. While 13 tools are registered (verified in server_test.go), the source code reveals almost NO visible input schemas, parameter descriptions, or output documentation. Tool names follow verb_noun convention, but descriptions are missing or minimal. The codebase shows test registration only (server_test.go TestNewServerRegistersExpectedTools lists expected names), but actual tool implementation details are not included in the provided source. For 11 of 13 tools, only the tool name and risk category are visible, no schema, no parameter descriptions, no output documentation. Only 2 tools (jira.search_issues, jira.update_issue, jira.add_attachment, confluence.search_pages) show any parameter structure in the summary, but even these lack full schema definitions in the source. Without visible handler implementations or explicit schema registration code, we must cap per-tool scores at 50 per the inference rule. The server uses mark3labs/mcp-go which should support schema registration, but the schemas themselves are not present in the provided source files (server.go, server_test.go, main.go).
Missing tool descriptions (11 of 13 tools). LLMs cannot determine when or why to select a tool without a non-empty description. Examples: jira.list_projects, jira.create_issue, jira.update_issue, jira.add_comment, jira.list_transitions, jira.transition_issue, confluence.list_spaces, confluence.create_page, confluence.update_page, confluence.get_page have no visible description in source.
Input schemas not visible in source code for 11 of 13 tools. Only jira.search_issues, jira.update_issue, jira.add_attachment, and confluence.search_pages show partial parameter information in the summary. Full schema definitions (required by MCP) must be explicitly registered in the handler code, but handler implementations are not included in the provided source files (server.go only shows server construction, not tool handler registration details).
jira.list_projects
Recommendations
Add comprehensive tool descriptions (50 - 200 characters each) to all 13 tools. Each description must answer: What does it do? When should the LLM call it? What does it return? Example for jira.search_issues: 'Search Jira issues using JQL (Jira Query Language). Provide a valid JQL query like "project = PROJ AND status = Open". Returns matching issues with fields: key, summary, status, assignee, created. Call jira.list_projects first to discover valid project keys.'
Document full input schemas for all tools. For each parameter, specify: type (string|number|boolean|array|object), description (50 - 150 chars), and constraints (enum, pattern, min, max, minLength, maxLength). Example for jira.search_issues jql param: {"type": "string", "description": "JQL query string (Jira Query Language). Use logical operators (AND, OR, NOT) to filter. Examples: 'project = PROJ AND status = Open', 'assignee = currentUser()', 'created >= -7d'. Max 4096 characters."}
Document output schemas for all tools. Specify what fields are returned, their types, and which can be passed to downstream tools. Example for jira.search_issues: Returns {"issues": [{"key": string, "summary": string, "status": string, "assignee": {"name": string, "email": string}, "created": ISO8601 date}], "total": number}. key and assignee.email can be passed to jira.update_issue and jira.add_comment.
Add pagination support to list and search tools. jira.list_projects, jira.search_issues, confluence.list_spaces, confluence.search_pages should accept optional 'limit' (default 20, max 100) and 'offset' (default 0) parameters. Return {"items": [...], "total": number, "hasMore": boolean} to guide agent iteration.
Parameter descriptions missing or incomplete. Tools like jira.search_issues show only 'JQL query string' for the jql parameter, but lack details on format, valid JQL syntax, max length, or examples of what queries are valid. Parameter descriptions should be 50 - 150 characters explaining WHAT the parameter controls and WHEN to use it.
No output schema documentation visible. LLMs need to know what fields to expect from tool responses so they can plan downstream tool calls. Without documented return types, agents cannot understand how to chain tools (e.g., after jira.search_issues returns issues, what fields are available to pass to jira.update_issue?).
No pagination support documented. Tools like jira.list_projects, jira.search_issues, confluence.list_spaces, confluence.search_pages should accept limit/offset or page parameters and return a total count or next_cursor. Without pagination, large result sets blow the context window.
Tool implementation details not visible in source. The provided files (server.go, server_test.go, main.go) show server construction and tool registration by name only. Actual handler functions (NewJiraTools, NewConfluenceTools) are called but their implementation is not included. Per the inference rule, tools inferred rather than directly visible are capped at 50 overall.
Destructive operations (jira.create_issue, jira.update_issue, jira.transition_issue, confluence.create_page, confluence.update_page) lack confirmation/dry-run documentation. Agents should have a way to preview changes before committing irreversible operations.
No error recovery guidance visible. The test file shows handleSearchIssues returns an error for empty JQL, but the response format and error messages are not documented in tool descriptions. LLMs need explicit recovery guidance, e.g., 'If JQL query is empty, provide a valid query like "status = Open" or call jira.list_projects() first to find valid project keys.'
jira.search_issuesconfluence.search_pages
Add error handling guidance to tool descriptions. Example: 'If the tool returns "Issue not found", verify the issue key is correct. Call jira.search_issues with a project filter to find valid issues. If the project key is unknown, call jira.list_projects to discover available projects.'
Implement and document parameter validation for enum-like fields. For status transitions (jira.transition_issue), specify allowed transition names, e.g., "transition must be one of: To Do, In Progress, Done (case-insensitive)."
Add confirmation/dry-run support for destructive operations. Document that update_issue and create_page support an optional 'dryRun' parameter that returns the preview without persisting changes.
Include chaining IDs in responses. If jira.create_issue returns an issue, ensure the response includes {"key": "PROJ-123", ...} so the LLM can immediately pass key to jira.add_comment or jira.update_issue without a follow-up lookup.
Document permission/scope requirements for each tool. Example: 'jira.create_issue requires write:jira-issues scope. jira.list_projects requires read:jira-projects scope.' This enables least-privilege agent configuration.
Add tool descriptions that disambiguate similar names. Example: 'jira.list_projects returns all projects the user has access to; jira.search_issues finds specific issues within a project. Use list_projects first to discover available projects, then search_issues to find work items.'
Specify natural identifier support for user/account parameters. If jira.update_issue accepts assignee, document whether it accepts email, username, or display name. Example: 'assignee can be an email ([email protected]), username (jdoe), or user ID (U12345). Usernames are resolved server-side; opaque IDs are passed directly.'
Cap response sizes and document limits. Example: 'jira.search_issues returns a maximum of 100 issues per call. Use offset and limit parameters to paginate. If more issues match the query, set offset += limit and call again.'
Provide examples of common use cases in parameter descriptions (but not sample values that LLMs will copy literally). Example: 'jql can filter by status, assignee, reporter, created date, and custom fields. Common patterns: find my open tasks, find tasks in a project, find overdue items. See Atlassian JQL docs for syntax.'
Add tool annotations (readOnlyHint, destructiveHint, idempotentHint) via MCP tool definitions. Mark jira.list_projects and confluence.search_pages as readOnlyHint: true. Mark jira.create_issue, jira.update_issue, jira.transition_issue, confluence.create_page, confluence.update_page as destructiveHint: true.