Skip to main content
Glama

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 — owner approves → renter pays at the URL → confirmed

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

rigshare_check_availability

equipment:read

Unavailability blocks for a listing

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. 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_sync_availability

equipment:write

Push an ERP / fleet calendar's blocks onto a listing

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. 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)

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 hit the /api/v1/agent/* surface using Bearer auth and respect the API key's configured scopes + budget 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/RPER2001/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_KEYOptional. Enables the authenticated tools (list_my_bookings, list_my_sessions, create_booking). Without it, those tools return a descriptive error. Get a key at https://www.rigshare.app/profile#api-keys or email support@rigshare.app.

  • RIGSHARE_API_BASE — override the public API base URL. Defaults to https://www.rigshare.app/api/public/v1. Useful for staging or local development.

  • RIGSHARE_AGENT_API_BASE — override the authenticated agent API base URL. Defaults to https://www.rigshare.app/api/v1/agent.

Claude Desktop config with API key

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

Scopes required for each authenticated tool:

Tool

Minimum scope

rigshare_list_my_bookings

bookings:read

rigshare_list_my_sessions

sessions:read

rigshare_create_booking

bookings:write

Keys can be scoped narrowly (read-only) or broadly (read+write+booking), and you can set per-key daily/monthly budget caps. Manage at https://www.rigshare.app/profile#api-keys.

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 / ... │              └────────────────┘          └────────────────────────────┘
└────────────────┘

No auth, no cookies, no user accounts — the agent reads the same data you'd see browsing rigshare.app publicly.

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.

Get an API key at https://www.rigshare.app/profile#api-keys or email support@rigshare.app. Keys are scoped (equipment:read, equipment:write, bookings:read, bookings:write, sessions:read, sessions:write) and carry configurable per-transaction and daily budget caps.

The human stays in the loop for money. A booking created by an agent is paid by the renter at the booking URL after the owner approves (unless auto-pay is enabled on the key by its owner); 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 — a date-only start is refused, and the session must start by 4:00 PM local. HOURLY bookings are billed per whole 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.RPER2001/rigshare. Search for it in your MCP client, or verify directly:

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

Contributing

Bug reports + PRs welcome. This public repo mirrors the MCP-server portion of the main RIGShare monorepo (which stays private for the commercial marketplace code). Changes flow from the monorepo → this repo on each release; for hot fixes you can also PR directly here.

License

MIT. Copyright © 2026 RIGShare LLC. Contact: support@rigshare.app · https://www.rigshare.app

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
NameRequiredDescriptionDefault
equipment_idYesFrom rigshare_search_equipment or rigshare_get_equipment.
start_dateYesISO-8601 start datetime.
end_dateYesISO-8601 end datetime. Must be after start_date.
duration_typeYesDetermines which rate is used. Must match a rate the equipment actually offers (e.g., use HOURLY only when equipment has a rateHourly).
pickup_typeNoDefault REMOTE_ACCESS for robotics/AI equipment. Use SELF_PICKUP or OWNER_DELIVERY for construction equipment.REMOTE_ACCESS
idempotency_keyNoOptional. 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
NameRequiredDescriptionDefault
idYesEquipment 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
NameRequiredDescriptionDefault
equipment_typeNoOptional. 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_hintNoOptional. 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
NameRequiredDescriptionDefault

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
NameRequiredDescriptionDefault
statusNoFilter to a specific booking status.
limitNo
pageNo

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
NameRequiredDescriptionDefault
booking_idNo
statusNo

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
NameRequiredDescriptionDefault
divisionNoRestrict to one division or search all.all
categoryNoExact category code (e.g. GPU_COMPUTE, HUMANOID_ROBOTS, EXCAVATORS). Use rigshare_list_categories to discover valid values. Overrides division filter.
remote_onlyNoIf true, only return listings with remote access enabled (SSH / Jupyter / VNC / API).
access_typeNoFilter to a specific remote access type.
searchNoFree-text search against the listing title.
min_price_daily_usdNoMinimum daily rate in USD.
max_price_daily_usdNoMaximum daily rate in USD.
cityNo
stateNoTwo-letter US state code.
sortNonewest
pageNo
limitNoResults 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.

  1. 7 tool updatesv1.1.3
    • 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

TDQS

A4.3/5.0

Scored 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.

Related MCP Connectors

Related MCP Servers