What can you do with this server?

rigshare-mcp connects an MCP-compatible AI agent to the RIGShare equipment rental marketplace, letting it search construction and Robotics & AI listings, book rentals, and manage remote sessions. * Search equipment (no auth) — filter listings by division (construction / robotics-ai / all), category, city/state, price range, remote-only, and access type (SSH, Jupyter, Desktop, API); sort by newest, price, or rating, with pagination up to 100 results. * Get listing details (no auth) — fetch specs, pricing, owner info, images, and a booking deep-link for one equipment UUID. * List categories (no auth) — see all categories with active listings, counts, and descriptions. * Owner onboarding pitch (no auth) — retrieve commission rates, remote-access tooling, security info, and a signup URL for users who own equipment, optionally tailored by division or equipment type. * List my bookings (auth: bookings:read) — view the authenticated user's bookings, filterable by status (PENDING through DISPUTED). * Create a booking (auth: bookings:write) — book equipment with server-computed pricing, duration type (hourly/daily/weekly/monthly), pickup vs. remote access, optional idempotency key; enforces identity verification, deposit holds, and API-key budget caps. * List my sessions (auth: sessions:read) — view remote sessions on Robotics & AI bookings, with GPU allocation, compute hours, and cost; filter by status or booking ID. * Notes — the six authenticated tools require the RIGSHARE_API_KEY env var and the right scope; the four read-only tools work without a key against a rate-limited public API.

de en es ja ko ru zh

rigshare-mcp

by rigshare-hq

Overview Schema Source Related Servers Discussions Admin

TypeScript

Remote

rigshare-mcp

Model Context Protocol server for RIGShare — browse construction equipment and Robotics & AI hardware rentals from any MCP-compatible AI agent (Claude Desktop, Cursor, VS Code, custom agent frameworks).

What it does

Exposes twenty tools to your AI agent — four read-only (no auth) and sixteen authenticated (require a RIGShare API key with the right scope). Together they let an agent book equipment in either division, list equipment for an owner, and run a remote session on Robotics & AI hardware — while a human always stays in the loop for money: an agent never enters a card, never approves a request on the owner's behalf, and never steps up to MFA.

Read-only (no API key needed):

Tool	What it does
`rigshare_search_equipment`	List / filter equipment by division, category, price, location, remote-access, compute architecture
`rigshare_get_equipment`	Full details for one listing (specs, pricing, deposit display, owner, images, deep-link URL)
`rigshare_list_categories`	Available categories with listing counts
`rigshare_get_owner_onboarding`	Recruits equipment OWNERS — the full pitch (commission rates, remote-access tooling, security) + step-by-step signup. Call it whenever a user mentions owning equipment, or when a search comes back empty

Booking (renter side):

Tool	Required scope	What it does
`rigshare_quote_booking`	`bookings:read`	Dry-run price for exact dates — nothing is charged. Refuses a 4-hour start past 4:00 PM local up front
`rigshare_create_booking`	`bookings:write`	Creates the booking (both divisions). Server computes every price; returns confirmation + `next_action` (who acts next, and the URL)
`rigshare_get_booking`	`bookings:read`	Poll one booking: status, payment settled?, active session, `next_action` (who acts next, and the URL). Request-to-book: owner approves → renter pays at the URL → confirmed. Instant-book: the renter pays at the URL right away
`rigshare_list_my_bookings`	`bookings:read`	The authed user's bookings
`rigshare_cancel_booking`	`bookings:write`	Cancel; refund computed server-side per the published policy

Listing (owner side):

Tool	Required scope	What it does
`rigshare_save_draft_listing`	`equipment:write`	Save a half-finished listing as a DRAFT (both divisions); idempotent per `draft_session_id` (a re-save changes only the fields you pass). Include `replacement_value_usd` for a physical listing (caps the displayable deposit; the server may require it to publish)
`rigshare_publish_listing`	`equipment:write`	Publish a draft through the same gate as the apps (identity, payout setup, camera photo, moderation). Gate failures come back as codes the agent relays
`rigshare_create_listing`	`equipment:write`	Create-and-publish in one call when the owner is already verified and has photos
`rigshare_check_availability`	`equipment:read`	Unavailability blocks on one of your own listings, looked up by its `external_id`
`rigshare_sync_availability`	`equipment:write`	Push an ERP / fleet calendar's blocks onto one of your listings (replaces the previously synced blocks)

Remote sessions (Robotics & AI):

Tool	Required scope	What it does
`rigshare_start_session`	`sessions:write`	Create + start a remote session on a CONFIRMED booking; returns the one-time access token and connect handoff. A repeat call while the session is live returns that session. Needs the rental agreement signed by both parties; MFA-protected listings must be started from the web/mobile app
`rigshare_get_session`	`sessions:read`	Status, health, usage, metered budget vs billed, latest telemetry
`rigshare_get_session_usage`	`sessions:read`	Live budget snapshot for a METERED booking
`rigshare_extend_session`	`sessions:write`	Raise the authorized budget (money path — confirm with the renter). Needs auto-pay enabled on the key and stays within the key's spend caps
`rigshare_end_session`	`sessions:write`	Stop the per-minute meter; settles exact usage
`rigshare_list_my_sessions`	`sessions:read`	Active + historical sessions

Read-only tools hit the public API (100 req/min/IP). Authenticated tools call the /api/v1/agent/* and /api/v1/* endpoints using Bearer auth and respect the API key's scopes and, where set, its spend caps.

Related MCP server: hive-mcp-depin

Use cases

For ML / AI engineers:

"Find me the cheapest H100 available this weekend"
"Are there any A100 80GB setups with SSH access right now?"
"What's the going rate for inference GPUs on RIGShare?"

For robotics researchers:

"Which humanoid robots can I rent for bipedal locomotion testing?"
"Show me industrial arms with camera feeds under $200/day"

For construction contractors:

"Find an excavator under 10 tons in Texas"
"What scissor lifts are available this week in Salinas?"

For AI procurement agents:

"Give me a list of all rentable 3D printers in California, sorted by price"

For equipment owners (supply-side recruitment):

"I have a Unitree G1 humanoid sitting idle — how do I rent it out?"
"I own a 4x H100 rig — is there a marketplace for this?"
"We have 3 excavators our crew only uses 60% of the time. Can we rent the rest out?"

For any of these, the agent calls rigshare_get_owner_onboarding (optionally with the equipment type) and gets back the full pitch: commission rates, the right signup URL, the step-by-step process, and the division-specific pitch (remote-access for robotics/AI, GPS + insurance for construction).

Installation

Claude Desktop

Add to your claude_desktop_config.json (Settings → Developer → Edit Config):

{
  "mcpServers": {
    "rigshare": {
      "command": "npx",
      "args": ["-y", "rigshare-mcp"]
    }
  }
}

Restart Claude Desktop. You should see "rigshare" in the 🔌 MCP servers list in the chat input area.

Cursor

~/.cursor/mcp.json:

{
  "mcpServers": {
    "rigshare": {
      "command": "npx",
      "args": ["-y", "rigshare-mcp"]
    }
  }
}

VS Code (Continue extension)

Add to your Continue config under mcpServers:

{
  "rigshare": {
    "command": "npx",
    "args": ["-y", "rigshare-mcp"]
  }
}

Any MCP-compatible agent framework

Launch with stdio transport:

npx -y rigshare-mcp

Testing locally

# Clone this repo
git clone https://github.com/rigshare-hq/rigshare-mcp.git
cd rigshare-mcp

npm install
npm run build

# Run the server (reads MCP protocol on stdin, writes to stdout)
npm start

# Diagnostic output goes to stderr:
# > rigshare-mcp server running on stdio

Then point your MCP client at the local build by changing the config:

{
  "mcpServers": {
    "rigshare-local": {
      "command": "node",
      "args": ["/absolute/path/to/rigshare-mcp/dist/index.js"]
    }
  }
}

Environment variables

RIGSHARE_API_KEY — Optional. Enables the 16 authenticated tools. Without it, those tools return a descriptive error and the 4 read-only tools still work. Create a key at https://www.rigshare.app/enterprise (API keys need a Pro or Enterprise plan) or email support@rigshare.app.
RIGSHARE_BASE — override the RIGShare host that every API base below derives from. Defaults to https://www.rigshare.app.
RIGSHARE_API_BASE — override the public API base URL. Defaults to https://www.rigshare.app/api/public/v1.
RIGSHARE_AGENT_API_BASE — override the authenticated agent API base URL. Defaults to https://www.rigshare.app/api/v1/agent.
RIGSHARE_V1_API_BASE — override the owner equipment/availability API base URL. Defaults to https://www.rigshare.app/api/v1.

Claude Desktop config with API key

{
  "mcpServers": {
    "rigshare": {
      "command": "npx",
      "args": ["-y", "rigshare-mcp"],
      "env": {
        "RIGSHARE_API_KEY": "rigs_live_..."
      }
    }
  }
}

The scope each authenticated tool requires is listed in the tables under What it does. Keys can be scoped narrowly (read-only) or broadly (read+write+booking). A key can also carry an optional per-transaction spend cap and an optional daily spend cap (there is no monthly cap). A new key has neither cap and has auto-pay off; neither is set from the key page, so contact support@rigshare.app about them. Create and revoke keys at https://www.rigshare.app/enterprise.

How the data flows

┌────────────────┐  MCP stdio   ┌────────────────┐  HTTPS   ┌────────────────────────────┐
│ Claude Desktop │ ◄──────────► │  rigshare-mcp  │ ───────► │  rigshare.app/api/public/v1 │
│  / Cursor /    │              │   (this pkg)   │          │  (read-only, rate-limited)  │
│  VS Code / ... │              └────────────────┘          └────────────────────────────┘
└────────────────┘

The read-only tools use no auth, cookies or user accounts — the agent reads the same data you'd see browsing rigshare.app publicly. The authenticated tools call the agent and owner endpoints (/api/v1/agent/*, /api/v1/*) with your API key.

Write operations

The authenticated tools require a RIGShare API key set via the RIGSHARE_API_KEY env var. Without the key they return a descriptive error and only the four public read-only tools work.

Create an API key at https://www.rigshare.app/enterprise (API keys need a Pro or Enterprise plan) or email support@rigshare.app. Keys are scoped (equipment:read, equipment:write, bookings:read, bookings:write, sessions:read, sessions:write) and can carry an optional per-transaction spend cap and an optional daily spend cap. A booking is checked against them before sales tax is added. A new key has neither.

The human stays in the loop for money. A booking created by an agent is paid by the renter at the booking URL: right away on an instant-book listing, after the owner approves on a request-to-book listing. The exception is auto-pay: when it is enabled on the key, an instant-book booking is paid with the renter's saved card as it is created (a per-minute listing's budget is authorized as a card hold). Auto-pay is off on a new key, and extending a session's budget needs it. A listing is published only after the owner completes identity verification and payout setup in the app; a remote session on MFA-protected equipment must be started from the web or mobile app. rigshare_get_booking always tells the agent who has to act next.

Start times for short rentals. For FOUR_HOURS bookings send start_date / end_date as ISO date-times with a UTC offset in the equipment's local time; the session must start by 4:00 PM local. A date-only start is read as UTC midnight: it is usually refused, but in Pacific time in winter, Alaska and Hawaii it books a four-hour block on the previous afternoon. HOURLY bookings are billed for every started hour between the two instants, so send real date-times there as well.

The full authenticated-API surface is documented at https://www.rigshare.app/openapi.json.

Registry listing

This server is published to the Official MCP Registry as io.github.rigshare-hq/rigshare. Search for it in your MCP client, or verify directly:

curl "https://registry.modelcontextprotocol.io/v0.1/servers?search=rigshare"

Contributing

Bug reports and suggestions are welcome — open an issue on this repository or email support@rigshare.app. This repository is updated automatically whenever the package changes, so changes are not merged here directly; accepted fixes arrive in a later update.

License

Available Tools

7 tools

rigshare_create_bookingA

REQUIRES API KEY (bookings:write scope). Creates a new RIGShare booking for the authenticated user. Server computes all prices from the equipment's canonical rates — client-side price hints are ignored. Enforces identity verification, security deposit hold, and a daily/monthly budget cap configured on the API key. Returns confirmation code + booking ID on success. Use rigshare_list_my_bookings to check status afterwards.

ParametersJSON Schema

Name	Required	Description	Default
`equipment_id`	Yes	From rigshare_search_equipment or rigshare_get_equipment.
`start_date`	Yes	ISO-8601 start datetime.
`end_date`	Yes	ISO-8601 end datetime. Must be after start_date.
`duration_type`	Yes	Determines which rate is used. Must match a rate the equipment actually offers (e.g., use HOURLY only when equipment has a rateHourly).
`pickup_type`	No	Default REMOTE_ACCESS for robotics/AI equipment. Use SELF_PICKUP or OWNER_DELIVERY for construction equipment.	REMOTE_ACCESS
`idempotency_key`	No	Optional. If provided, repeated calls with the same key within 5 minutes return the same booking instead of creating duplicates.

TDQS

A4.1/5.0

Behavior4/5

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

Discloses important behaviors: server computes prices (ignoring client hints), enforces identity verification, security deposit hold, and budget cap. No annotations exist, so description carries full burden, and it does so well.

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?

Concise paragraph with front-loaded requirement. Each sentence adds unique information; no redundancy. Slightly dense but effective.

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?

Covers auth, return value, idempotency, constraints, and follow-up action. Lacks error scenarios, but for a creation tool with no output schema, provides solid contextual completeness.

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

Parameters4/5

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

Schema coverage is 100%, but description adds value by explaining server-side pricing and providing context for pickup_type and idempotency_key behavior, enhancing understanding beyond schema.

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?

Clearly states it creates a booking for the authenticated user, with prerequisite API key and scope. Distinguishes from siblings by noting follow-up use of rigshare_list_my_bookings.

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

Usage Guidelines3/5

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

Provides context on server-side pricing and idempotency, and suggests post-usage check, but lacks explicit when-to-use vs. alternatives (other booking tools are not creation-related).

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

rigshare_get_equipmentA

Fetch full details for a single RIGShare equipment listing by its UUID. Returns specs, pricing, owner info, images, and a deep-link URL for booking.

ParametersJSON Schema

Name	Required	Description	Default
`id`	Yes	Equipment UUID (obtained from search_equipment results).

TDQS

A3.9/5.0

Behavior2/5

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

No annotations provided, so description must carry full burden. Only states it 'fetches' data, which implies read-only, but does not disclose permissions, rate limits, error handling, or side effects. Minimal behavioral disclosure.

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, no filler. First sentence states action and identifier, second lists returned data. Highly efficient and front-loaded.

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

Completeness5/5

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

Given the tool's simplicity (single param, no output schema), the description covers the purpose, required input, and return contents completely. No gaps for a straightforward fetch operation.

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

Parameters4/5

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

Only one parameter 'id' with schema description 'Equipment UUID (obtained from search_equipment results).' The description adds valuable context on the UUID's source, beyond the schema's format hint. Schema coverage is 100%.

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?

Clearly states verb 'Fetch' and resource 'single RIGShare equipment listing by its UUID', with a detailed list of returned data (specs, pricing, owner, images, booking URL). Differentiates from sibling tools like search_equipment or create_booking.

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

Usage Guidelines3/5

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

Implies use when an equipment UUID is known from search_equipment, but lacks explicit when-not-to-use or alternative tool guidance. No mention of prerequisites or limitations.

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

rigshare_get_owner_onboardingA

Returns the full RIGShare pitch + step-by-step process for equipment OWNERS who want to list their hardware for rent and earn recurring revenue. Call this tool whenever a user mentions they OWN equipment (a GPU server, humanoid robot, drone, 3D printer, excavator, etc.) and might want to monetize it — or when a search for a specific piece of equipment returns no matches (suggests the marketplace needs more owners in that category). Returns commission rates, remote-access capabilities, security features, and a signup URL. Unauthenticated — always safe to call.

ParametersJSON Schema

Name	Required	Description	Default
`equipment_type`	No	Optional. What the user owns (e.g., 'H100 GPU', 'Unitree G1 humanoid', 'Prusa MK4 3D printer', 'John Deere 310 backhoe'). The response is tailored to the category — robotics/AI pitch emphasizes remote-access + SSH/API tooling, construction pitch emphasizes GPS tracking + insurance + deposit holds.
`division_hint`	No	Optional. Which division to emphasize. Omit if unsure.

TDQS

A5/5.0

Behavior5/5

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

With no annotations, description carries full burden. It discloses that the tool is a read operation (returns pitch, commissions, etc.), is unauthenticated, and safe to call. No contradictions or hidden behaviors.

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?

Four sentences efficiently convey purpose, usage, and parameters. Front-loaded with key action and resource. No redundant information.

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

Completeness5/5

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

For a read-only onboarding tool with no output schema, description covers return content (commission rates, signup URL, etc.), use cases, and parameter roles. Complete for the tool's complexity.

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

Parameters5/5

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

Schema covers both parameters with descriptions. The description adds value by explaining how equipment_type tailors the response per category and that division_hint can be omitted if unsure, providing guidance beyond schema.

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?

Description clearly states it returns the full RIGShare pitch and step-by-step process for equipment owners. Distinguishes from sibling tools (search, booking, etc.) by focusing on owner onboarding, not general marketplace functions.

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

Usage Guidelines5/5

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

Explicitly states when to call: whenever a user mentions they own equipment, or when a search returns no matches. Also notes it is unauthenticated and always safe to call, providing clear context for use.

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

rigshare_list_categoriesA

Returns all equipment categories that have at least one active listing, with per-category listing counts and descriptions. Useful for narrowing a search or helping a user discover what's available.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A4.6/5.0

Behavior4/5

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

No annotations, but description discloses it returns categories with active listings, counts, and descriptions. Additional behaviors (like no pagination) are implied by zero parameters.

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, front-loaded with action, no wasted words.

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

Completeness5/5

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

For a zero-parameter tool, the description covers purpose, result content, and usage context. No missing details.

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

Parameters5/5

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

Input schema has no parameters and 100% coverage. Description confirms no filters, adding no confusion.

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 returns all equipment categories with active listings, including counts and descriptions, and provides a use case. No ambiguity.

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?

The description says it's useful for narrowing a search or discovering what's available, indicating when to use it. No explicit alternatives, but siblings don't overlap.

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

rigshare_list_my_bookingsA

REQUIRES API KEY (RIGSHARE_API_KEY env var, bookings:read scope). Returns the authenticated user's RIGShare bookings — equipment, dates, status, totals. Use this to check an existing rental before creating a new one, or to track a confirmation code.

ParametersJSON Schema

Name	Required	Description
`status`	No	Filter to a specific booking status.
`limit`	No
`page`	No

TDQS

A3.8/5.0

Behavior3/5

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

With no annotations provided, the description must disclose behavioral traits. It mentions authentication requirements (API key, scope) and the fields returned. However, it does not detail pagination behavior, default sorting, rate limits, or response size limits, leaving some gaps.

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?

The description is two concise sentences that front-load the critical requirement (API key and scope). Every sentence adds value without redundancy or unnecessary elaboration.

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

Completeness3/5

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

Given no output schema, the description should fully explain the response. It lists fields but omits details on pagination, default sorting, how to retrieve all bookings, or any example. The input schema defaults are present but not explained, leaving the tool contextually incomplete.

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?

Only 33% of schema parameters have descriptions (status has a description; limit and page lack any). The description does not add extra meaning to these parameters beyond their schema definitions, failing to compensate for the low coverage.

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 it returns the authenticated user's bookings with specific fields (equipment, dates, status, totals). It distinguishes from siblings like 'rigshare_create_booking' and 'rigshare_search_equipment' by focusing on listing existing bookings for the user.

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?

The description explicitly recommends using this tool to check existing rentals before creating a new one or to track a confirmation code. It also mentions the API key requirement and scope, but does not explicitly state when not to use it or list alternatives.

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

rigshare_list_my_sessionsA

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.

ParametersJSON Schema

Name	Required	Description	Default
`booking_id`	No
`status`	No

TDQS

A4.1/5.0

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.

rigshare_search_equipmentA

Search RIGShare's rental equipment marketplace by filters. Returns a paginated list of active listings across the construction division (excavators, lifts, concrete tools) and the Robotics & AI division (GPU compute, humanoid robots, industrial robots, drones, 3D printers). Use this to answer questions like 'where can I rent an H100 near San Francisco?' or 'find a humanoid robot under $200/day'. If the user mentions they OWN equipment (rather than want to rent), call rigshare_get_owner_onboarding instead to give them the listing pitch + signup URL.

ParametersJSON Schema

Name	Required	Description	Default
`division`	No	Restrict to one division or search all.	all
`category`	No	Exact category code (e.g. GPU_COMPUTE, HUMANOID_ROBOTS, EXCAVATORS). Use rigshare_list_categories to discover valid values. Overrides division filter.
`remote_only`	No	If true, only return listings with remote access enabled (SSH / Jupyter / VNC / API).
`access_type`	No	Filter to a specific remote access type.
`search`	No	Free-text search against the listing title.
`min_price_daily_usd`	No	Minimum daily rate in USD.
`max_price_daily_usd`	No	Maximum daily rate in USD.
`city`	No
`state`	No	Two-letter US state code.
`sort`	No		newest
`page`	No
`limit`	No	Results per page (max 100).

TDQS

A4.8/5.0

Behavior5/5

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

With no annotations provided, the description effectively covers behavioral traits: it returns only active listings, supports pagination, and notes that category overrides division filter. It gives division examples and filter semantics, fully compensating for the lack of annotations.

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?

The description is extremely concise: two main sentences plus a third for usage guidance. It is front-loaded with purpose and example queries, with no redundant information.

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?

Given 12 parameters, no output schema, and no annotations, the description provides solid context: divisions, example queries, sibling tool guidance, and category usage. It could mention pagination specifics or default return fields, but what's present is sufficient for effective use.

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

Parameters4/5

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

Schema description coverage is 75% (9 of 12 parameters documented). The description adds value by explaining divisions, citing example queries, and clarifying that category overrides division. It also directs users to rigshare_list_categories for valid category codes, aiding parameter selection.

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 searches a rental equipment marketplace by filters, returning paginated active listings across two divisions. It provides concrete example queries and distinguishes itself from the sibling tool for owner onboarding.

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

Usage Guidelines5/5

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

The description explicitly tells when to use this tool (searching for rentals) and when to use the alternative rigshare_get_owner_onboarding. It also references rigshare_list_categories for discovering category codes.

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

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

7 tool updatesv1.1.3May 5, 2026
- First observedrigshare_create_booking
- First observedrigshare_get_equipment
- First observedrigshare_get_owner_onboarding
- First observedrigshare_list_categories
- First observedrigshare_list_my_bookings
- First observedrigshare_list_my_sessions
- First observedrigshare_search_equipment

Deploy Server

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

TDQS

A4.3/5.0

Scored 2026-05-05 02:40 across 7 tools

Disambiguation5/5

Each tool targets a distinct action or resource: searching, fetching details, listing categories, managing bookings and sessions, and owner onboarding. No overlapping purposes.

Naming Consistency5/5

All tools follow the consistent pattern 'rigshare_verb_noun' (e.g., create_booking, search_equipment). Uniform verb and noun styles throughout.

Tool Count5/5

Seven tools cover the essential operations of a rental marketplace without bloat. The scope is well-defined and each tool serves a clear function.

Completeness4/5

Core workflows (search, view, book, check status) are covered. Missing update/cancel booking or payment details, but these are minor gaps for the primary use case.

Maintenance

ActivityMaintained

ResponsivenessNo issues

Resources

Need Help?

Related Servers

Related MCP Connectors

compute.pangle.online — GPU rental market B
online.pangle.compute
Live GPU rental market: 2,500+ offers across a dozen provider feeds. History, watches, limit orders.
Cloud Platforms AI & Machine Learning
251
AmpleRun GPU rentals A
com.amplerun
Find, price, rent and stop GPUs on AmpleRun. Paid in USDC or USDT on Base. Flat 5% fee.
Cloud Platforms Cryptocurrency Blockchain
21
Zhijiangyun Cloud (智匠云)
cloud.artibot
Robot embodied-AI cloud for GPU training, inference, benchmarks, and robot data collection.
AI & Machine Learning Cloud Platforms Autonomous Agents
11
FastGPU A
co.fastgpu
Compare live GPU cloud rental prices and match workloads to the cheapest provider.
Cloud Platforms AI & Machine Learning
21

Related MCP Servers

humanforaiofficial
Research & Data Testing & QA Tools
humanforai
A
license
A
quality
A
maintenance
Enables AI agents to hire real human operators for tasks requiring physical presence, human perception, or judgment, such as verification, testing, data collection, and physical-world tasks.
Updated a month ago (2026-08-29 11:29 UTC)
4
48 npm
1
MIT
hive-mcp-depin
Blockchain Cryptocurrency Web3 & Decentralized Tech
srotzin
A
license
Not graded
quality
B
maintenance
Enables listing and discovery of DePIN infrastructure capacity (storage, compute, GPU, etc.) with real USDC/USDT settlement across multiple chains.
Updated 2 months ago (2026-07-30 16:25 UTC)
MIT
Salvage & Surplus MCP
E-commerce & Retail Payments & Billing Cryptocurrency
Fish-Tacos
A
license
Not graded
quality
C
maintenance
MCP commerce surface for refurbished datacenter hardware — GPU rigs, server racks, drive arrays, and network gear, with x402 agent-payment discovery.
Updated 2 months ago (2026-08-16 20:33 UTC)
MIT
kwctl
Agent Orchestration Cloud Platforms AI & Machine Learning
KilaWattCloud
A
license
A
quality
A
maintenance
Zero-quota GPU orchestration MCP server — lets AI agents discover, provision, and manage GPU compute across multi-datacenter partner nodes (H100/H200/B200) through a single control plane.
Updated 3 days ago (2026-09-30 20:45 UTC)
1
222 npm
MIT

rigshare-mcp

What it does

Use cases

Installation

Claude Desktop

Cursor

VS Code (Continue extension)

Any MCP-compatible agent framework

Testing locally

Environment variables

Claude Desktop config with API key

How the data flows

Write operations

Registry listing

Contributing

License

Available Tools

Tool Schema Changelog

Maintenance

Resources

Related MCP Connectors

Related MCP Servers

humanforaiofficial