atlassian-browser-mcp
Related Servers
Alternatives to atlassian-browser-mcp
No user-submitted related servers found.
Related Servers
- FlicenseBqualityDmaintenancePlaywright wrapper for MCP that enables LLM-powered clients to control a browser for automation tasks.101-
- AlicenseNot gradedqualityBmaintenanceAn MCP server for Jira 8 that enables SSO-authenticated issue management, work logging, search, and more through natural language, using Playwright for session setup and running as a local subprocess.29 npmMIT
- FlicenseNot gradedqualityDmaintenanceExposes Playwright browser automation as MCP tools, enabling AI assistants to control a real browser tab-by-tab for form filling, navigation, and more, while preserving the user's active session.-
- AlicenseAqualityDmaintenanceMCP server that enables accessing Jira and Confluence using browser cookies captured via a Chrome extension, avoiding the need for API tokens or browser automation. It wraps the mcp-atlassian toolset and works with Atlassian Cloud and Server/Data Center behind SSO.11GPL 3.0
- AlicenseNot gradedqualityCmaintenanceMCP server for Atlassian Cloud (Confluence & Jira) with seamless OAuth 2.0 authentication. Enables AI agents to document work in Confluence, manage Jira issues, and understand project context.62 PyPI4MIT
- AlicenseNot gradedqualityAmaintenanceEnables AI agents and MCP clients to automate real browser sessions through Playwright-compatible tools, including web research, testing, persistent profiles, proxy matching, and humanized interactions, with npm, Docker, stdio, and Streamable HTTP deployment options.431 npmMIT
TDQS
Scored across 100 tools
Most tools target a distinct resource+action, but several clusters blur together: jira_get_issue (with its `include` param) overlaps with jira_get_issue_dates, jira_get_issue_sla, and jira_get_issue_development_info; four field-discovery tools (jira_search_fields, jira_get_field_options, jira_get_create_fields, jira_get_project_fields) require careful reading to choose correctly. Attachment/image tools across Jira and Confluence (jira_download_attachments vs jira_get_issue_images, confluence_download_attachment vs confluence_download_content_attachments vs confluence_get_page_images) are distinguishable only after reading long descriptions. Descriptions do help resolve most cases, so it lands in the middle.
Nearly every tool follows a strict service-prefixed verb_noun pattern: jira_* , confluence_*, atlassian_* with actions like get_, create_, update_, delete_, search_, add_, remove_. Exceptions like atlassian_auth_status and atlassian_login still fit the same convention. The prefixes also make the service boundary immediately legible.
100 tools is an extreme surface for a browser-session-based Jira/Confluence wrapper, far past the 50+ threshold. Many are niche (Service Desk Server/DC-only tools, ProForma form tools, SLA computation, cross-project dependency analysis, inline comments) that most agents will never need, diluting selection accuracy. A well-scoped server would consolidate these into parameterized operations.
Coverage of Jira and Confluence is genuinely broad: issues, sprints, boards, versions, components, links, worklogs, watchers, comments, attachments, templates, restrictions, and page history/diffs are all represented. Minor gaps remain, e.g. no delete-comment tool for Jira or Confluence and no sprint deletion, but agents can work around these with update/transition tools.