Skip to main content
Glama

rigshare_list_my_sessions

Check your active remote sessions on Robotics & AI bookings, including status, GPU allocation, compute hours, and cost. Use to avoid starting a new session if one is already active.

Instructions

REQUIRES API KEY (sessions:read scope). Lists the authenticated user's remote sessions on Robotics & AI bookings — status, GPU allocation, total compute hours, cost so far. Use before starting a new session to check if one is already active.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
booking_idNo
statusNo

Implementation Reference

  • The `listMySessions` async function that executes the tool logic. It checks for API key, calls the authenticated sessions endpoint, and formats session data (status, GPU allocation, compute hours, cost) into a readable text response.
    async function listMySessions(args: Record<string, unknown>) {
      if (!RIGSHARE_API_KEY) return toolError(API_KEY_ERROR_MSG);
    
      const params = new URLSearchParams();
      if (args.booking_id) params.set("booking_id", String(args.booking_id));
      if (args.status) params.set("status", String(args.status));
    
      const res = await fetchAuthJson(
        RIGSHARE_API_KEY,
        `${RIGSHARE_AGENT_API}/sessions?${params.toString()}`,
      );
      if (res.error) return toolError(res.error);
      const sessions = ((res.data as any)?.sessions || []) as any[];
      if (sessions.length === 0) {
        return toolText("No remote sessions found.");
      }
      const lines = sessions.map((s, i) => {
        return [
          `${i + 1}. ${s.accessType} session — status: ${s.status} (health: ${s.healthStatus})`,
          `   Booking ID: ${s.bookingId}`,
          `   Started: ${s.startedAt ? new Date(s.startedAt).toLocaleString() : "not started"}`,
          `   Compute hours: ${s.totalComputeHours ?? 0} · Cost so far: $${((s.totalCostCents || 0) / 100).toFixed(2)}`,
          s.gpuAllocation ? `   GPU: ${s.gpuAllocation}` : "",
        ]
          .filter(Boolean)
          .join("\n");
      });
      return toolText(`Your remote sessions:\n\n${lines.join("\n\n")}`);
    }
  • The tool definition with name 'rigshare_list_my_sessions', description, and inputSchema defining optional 'booking_id' (uuid) and 'status' (enum) parameters.
    {
      name: "rigshare_list_my_sessions",
      description:
        "REQUIRES API KEY (sessions:read scope). Lists the authenticated user's remote sessions on Robotics & AI bookings — status, GPU allocation, total compute hours, cost so far. Use before starting a new session to check if one is already active.",
      inputSchema: {
        type: "object",
        properties: {
          booking_id: { type: "string", format: "uuid" },
          status: {
            type: "string",
            enum: ["provisioning", "active", "paused", "terminated", "failed"],
          },
        },
      },
    },
  • src/index.ts:315-316 (registration)
    The switch-case registration in the CallToolRequestSchema handler that routes the tool name 'rigshare_list_my_sessions' to the `listMySessions` function.
    case "rigshare_list_my_sessions":
      return await listMySessions(args || {});
Behavior4/5

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

With no annotations, the description discloses required authentication (API key, scope) and lists returned fields (status, GPU, compute hours, cost). Implies read-only operation. Does not mention pagination or rate limits, but covers key behavioral aspects for a list tool.

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

Conciseness5/5

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

Two sentences: first states requirement and core function, second gives usage advice. No wasted words, front-loaded with critical info.

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?

Describes key return fields (status, GPU, compute hours, cost), compensating for lack of output schema. Omits pagination or response structure details, but adequate for a list tool with optional filters. Could improve by explaining parameters.

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

Parameters2/5

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

Input schema has 2 optional parameters (booking_id, status) with 0% description coverage. The description does not explain these parameters, leaving the agent uninformed about filtering capabilities. The schema itself provides enum values for status, but the description adds no contextual meaning.

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 clearly states the tool lists the authenticated user's remote sessions with specific fields (status, GPU allocation, compute hours, cost). It distinguishes from sibling tool 'rigshare_list_my_bookings' by targeting sessions instead of bookings.

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?

Provides explicit when-to-use guidance: 'Use before starting a new session to check if one is already active.' Also notes required API key and scope (sessions:read), which serves as a prerequisite. No explicit when-not or alternatives, but sufficient for typical use.

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

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/RPER2001/rigshare-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server