Claude Code MCP Server

Cloud session GitHub status

claude_get_session

Idempotent

Reads a cloud session job's progress, result, or error by job ID; with a session ID or URL, reports its pushed branch and opened pull request.

Instructions

With a job id from claude_create_cloud_session, report that create's progress in job (status, elapsed time, the tail of the CLI output, and session_id once the CLI prints it), its final result once job.status is done, or its error. With a job id from claude_run_local, report that run in local_job the same way. A job read uses memory only and runs nothing. With a session id or URL, report the branch a cloud session pushed and any pull request it opened. Prepares the github.com checkout in CLAUDE_MCP_REPO_CACHE (origin set to that repository), then runs print-mode claude --teleport=<session> --debug there and stops when the CLI exits. Print mode checks out the session branch and exits; it is not given a prompt and it is not started on a terminal, so it does not continue as a local interactive session. The branch is taken from the debug line Branch after checkout when that matches HEAD, otherwise from a HEAD move. The pull request number and URL come from that output when present, otherwise from a read-only gh pr list. Claude's GitHub app (or /web-setup) is what pushes the branch and opens the pull request; this tool only reads them.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "session": "<session>"
    },
    "name": "claude_get_session"
  }
}

Input Schema

Name	Required	Description	Default
`repo`	No	github.com owner/name the session was started in. Omit when this server created the session with repo set; that repository is recorded in the cache. Ignored for a job id.
`session`	Yes	What to read: a job id (job_...) returned by claude_create_cloud_session, or a cloud session id (session_... / cse_...) or https://claude.ai/code/... URL.

Output Schema

Name	Required	Description
`cli`	Yes
`job`	Yes	Set when `session` was a create job id: that create's progress or result. The other fields are then null, false or empty.
`args`	Yes
`repo`	Yes	github.com owner/name the status read used.
`branch`	Yes	Branch the cloud session pushed, or null when none is checked out yet.
`parsed`	Yes	True when the pushed branch was identified.
`pr_url`	Yes
`pr_error`	Yes	Set when gh could not look up a pull request. Null when there is no pull request.
`local_job`	Yes	Set when `session` was a claude_run_local job id: that run's progress or result. The other fields are then null, false or empty.
`pr_number`	Yes
`pr_source`	Yes	Where the pull request fields came from.
`session_id`	Yes
`base_branch`	Yes	Branch the cache was reset to before teleport.

Schema Changelog

Changes observed during successful MCP inspections.

Addedv0.1.3Nov 6, 2026

TDQS

A4.3/5.0

Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Beyond the annotations, the description discloses that a session read prepares a checkout in CLAUDE_MCP_REPO_CACHE, sets origin, and actually executes print-mode `claude --teleport=<session> --debug` locally until the CLI exits — which explains the non-read-only hint. It also explains branch detection (debug line `Branch after checkout` vs. HEAD move), the `gh pr list` fallback, and that the tool does not push branches or open PRs. No contradiction with readOnlyHint=false, destructiveHint=false, idempotentHint=true.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Nearly every sentence carries unique information — cache behavior, print-mode semantics, branch-source heuristics — with no filler. However, the sentences are long and tangle multiple clauses, and the primary 'get' behavior is buried behind conditionals rather than front-loaded.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a tool that spawns a local CLI, the description covers side effects, artifact locations, and output provenance thoroughly, and an output schema exists so return shape need not be spelled out. Minor gaps remain: no mention of auth prerequisites when `repo` is omitted and the cache lacks the repository, and no indication of expected duration or failure modes if `gh` is unavailable.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% and both parameters are already well documented, so the baseline is 3. The description adds the mode mapping (job id → `job`/`local_job`, session id/URL → branch and PR) which helps interpret `session`, but it adds nothing about `repo` beyond what the schema states (cache-recorded, ignored for job ids).

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description names the specific resources (job progress/result/error, local run, session branch and pull request) and ties each to the sibling that produces its id (claude_create_cloud_session, claude_run_local). Despite the tool name suggesting only sessions, the multi-mode scope is spelled out so an agent can distinguish it from siblings without opening the schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It gives clear input-driven routing: a job id from claude_create_cloud_session reads that job, a job id from claude_run_local reads that run, and a session id or URL reads the branch/PR. It also notes a job read 'uses memory only and runs nothing,' implying cheap polling. It never states exclusions, e.g. that a session read costs a real CLI run, so an agent may not realize the two modes have very different costs.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Deploy Server