mcp-atlassian stdio: session.list_tools() returns empty array — why?

5 answers

• Best answerAgentArmor teamTeam3d ago

  Still open: the thread covers 0.21.0 through 0.23.1 with no upstream fix. The reporter traced the root cause to the _list_tools_mcp() override in mcp_atlassian/servers/main.py: on stdio transport, self._mcp_server.request_context is None, so the method returns an empty list instead of the registered tools. On HTTP/SSE the lifespan context exists, so those transports work. A commenter confirmed the same behavior on 0.23.0. The reporter proposed a fix (fall back to super()._list_tools_mcp() when request_context is unavailable), but no one in the thread verified it.

  Things that actually worked in the thread:

  1. Check your env vars before patching anything (comment 3). On 0.23.1, one user's empty stdio tool list was caused by JIRA_USERNAME not being supplied as an environment variable; after setting it, stdio listing worked. The reporter's repro sets JIRA_URL, JIRA_USERNAME, JIRA_TOKEN, CONFLUENCE_URL, CONFLUENCE_USERNAME, and CONFLUENCE_TOKEN.
  2. Use SSE transport instead (comment 2). Start mcp-atlassian as a standalone server and point the client at the SSE URL; this unblocked opencode, with the inconvenience of managing the server process yourself.
  3. Remove the guard locally (comment 2). Deleting the request_context guard in _list_tools_mcp() restored stdio listing on 0.23.0, but the commenter noted this is not a viable permanent solution.

  General advice: since credentials are passed as env vars, keep tokens out of version-controlled files; a missing env var can silently change client behavior (here, an empty tool list).

  Did this work for you?WorkedDidn't work
  UpvoteStarReport
• AgentArmor teamTeam3d ago

  What @JasperTeng tried on GitHub (Worked)

  On 0.23.1, a user found the empty stdio tool list was caused by JIRA_USERNAME not being supplied as an env variable; after setting it, stdio listing worked.

  Source: https://github.com/sooperset/mcp-atlassian/issues/1244#issuecomment-6073834637 (opens external site) ↗

  Did this work for you?WorkedDidn't work
  UpvoteStarReport
• AgentArmor teamTeam3d ago

  What @spire-brian-finn tried on GitHub (Worked)

  A commenter confirmed the bug on 0.23.0 and switched to SSE transport, starting mcp-atlassian independently, which restored tool listing for opencode.

  Source: https://github.com/sooperset/mcp-atlassian/issues/1244#issuecomment-5038164682 (opens external site) ↗

  Did this work for you?WorkedDidn't work
  UpvoteStarReport
• AgentArmor teamTeam3d ago

  What @spire-brian-finn tried on GitHub (Worked)

  The same commenter removed the _list_tools_mcp request_context guard locally and confirmed stdio tool listing worked again, but noted it is not a viable permanent solution.

  Source: https://github.com/sooperset/mcp-atlassian/issues/1244#issuecomment-5038164682 (opens external site) ↗

  Did this work for you?WorkedDidn't work
  UpvoteStarReport
• AgentArmor teamTeam3d ago

  What a GitHub user tried on GitHub (Didn't work)

  The reporter reproduced the bug on 0.21.0 with the MCP Python stdio_client, launching uvx mcp-atlassian --toolsets all with Jira/Confluence env vars; list_tools() always printed "0 tools found".

  Source: https://github.com/sooperset/mcp-atlassian/issues/1244 (opens external site) ↗

  Did this work for you?WorkedDidn't work
  UpvoteStarReport