Skip to main content
Glama
deenesjakoruzh
RPER2001

rigshare-mcp

by RPER2001
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

rigshare-mcp

Model Context Protocol-Server für RIGShare — durchsuchen Sie Baumaschinen sowie Robotik- & KI-Hardware-Mietangebote von jedem MCP-kompatiblen KI-Agenten (Claude Desktop, Cursor, VS Code, benutzerdefinierte Agenten-Frameworks).

Was er macht

Stellt Ihrem KI-Agenten sieben Tools zur Verfügung — vier schreibgeschützte (keine Authentifizierung erforderlich) und drei authentifizierte (erfordern einen RIGShare-API-Schlüssel).

Schreibgeschützt (kein API-Schlüssel erforderlich):

Tool

Was es macht

rigshare_search_equipment

Auflisten / Filtern von Geräten nach Sparte, Kategorie, Preis, Standort, Fernzugriff

rigshare_get_equipment

Vollständige Details zu einem Angebot (Spezifikationen, Preise, Besitzer, Bilder, Deep-Link-URL)

rigshare_list_categories

Verfügbare Kategorien mit Anzahl der Angebote

rigshare_get_owner_onboarding

Wirbt GeräteBESITZER an — liefert das vollständige Pitch-Material (Provisionssätze, Fernzugriffs-Tools, Sicherheitsfunktionen) + Schritt-für-Schritt-Anleitung zur Anmeldung. Rufen Sie dies auf, wann immer ein Benutzer erwähnt, dass er Geräte BESITZT, die er vermieten möchte, ODER wenn eine Suche keine Ergebnisse liefert (Signal, dass der Marktplatz in dieser Kategorie Besitzer benötigt).

Authentifiziert (erfordert RIGSHARE_API_KEY Umgebungsvariable mit entsprechenden Scopes):

Tool

Erforderlicher Scope

Was es macht

rigshare_list_my_bookings

bookings:read

Die RIGShare-Buchungen des authentifizierten Benutzers — Geräte, Daten, Status, Summen

rigshare_list_my_sessions

sessions:read

Aktive + historische Fernsitzungen (GPU-Zuweisung, Stunden, Kosten)

rigshare_create_booking

bookings:write

Erstellen einer neuen Buchung. Der Server berechnet die Preise; Client-Hinweise werden ignoriert. Erzwingt Identitätsprüfung, Sicherheitsleistung und Budgetobergrenzen pro Schlüssel

Schreibgeschützte Tools greifen auf die öffentliche API zu (100 Anfragen/Min./IP). Authentifizierte Tools greifen auf die /api/v1/agent/*-Oberfläche unter Verwendung von Bearer-Authentifizierung zu und respektieren die konfigurierten Scopes + Budgetobergrenzen des API-Schlüssels.

Related MCP server: hive-mcp-depin

Anwendungsfälle

Für ML / KI-Ingenieure:

  • "Finde mir die günstigste verfügbare H100 für dieses Wochenende"

  • "Gibt es aktuell A100 80GB-Setups mit SSH-Zugriff?"

  • "Wie hoch ist der aktuelle Preis für Inferenz-GPUs auf RIGShare?"

Für Robotik-Forscher:

  • "Welche humanoiden Roboter kann ich für Tests zur zweibeinigen Fortbewegung mieten?"

  • "Zeige mir Industrieroboterarme mit Kamera-Feeds unter 200 $/Tag"

Für Bauunternehmer:

  • "Finde einen Bagger unter 10 Tonnen in Texas"

  • "Welche Scherenarbeitsbühnen sind diese Woche in Salinas verfügbar?"

Für KI-Beschaffungsagenten:

  • "Gib mir eine Liste aller mietbaren 3D-Drucker in Kalifornien, sortiert nach Preis"

Für Gerätebesitzer (Angebotsseite):

  • "Ich habe einen Unitree G1 humanoiden Roboter, der ungenutzt herumsteht — wie kann ich ihn vermieten?"

  • "Ich besitze ein 4x H100-Rig — gibt es dafür einen Marktplatz?"

  • "Wir haben 3 Bagger, die unsere Crew nur 60 % der Zeit nutzt. Können wir den Rest vermieten?"

Für all diese Fälle ruft der Agent rigshare_get_owner_onboarding auf (optional mit dem Gerätetyp) und erhält das vollständige Pitch-Material zurück: Provisionssätze, die richtige Anmelde-URL, den Schritt-für-Schritt-Prozess und den spartenspezifischen Pitch (Fernzugriff für Robotik/KI, GPS + Versicherung für das Baugewerbe).

Installation

Claude Desktop

Fügen Sie dies zu Ihrer claude_desktop_config.json hinzu (Einstellungen → Entwickler → Konfiguration bearbeiten):

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

Starten Sie Claude Desktop neu. Sie sollten "rigshare" in der Liste der 🔌 MCP-Server im Chat-Eingabebereich sehen.

Cursor

~/.cursor/mcp.json:

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

VS Code (Continue-Erweiterung)

Fügen Sie dies zu Ihrer Continue-Konfiguration unter mcpServers hinzu:

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

Jedes MCP-kompatible Agenten-Framework

Starten Sie mit stdio-Transport:

npx -y rigshare-mcp

Lokal testen

# 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

Zeigen Sie dann mit Ihrem MCP-Client auf den lokalen Build, indem Sie die Konfiguration ändern:

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

Umgebungsvariablen

  • RIGSHARE_API_KEY — Optional. Aktiviert die authentifizierten Tools (list_my_bookings, list_my_sessions, create_booking). Ohne diesen geben diese Tools einen beschreibenden Fehler zurück. Holen Sie sich einen Schlüssel unter https://www.rigshare.app/profile#api-keys oder senden Sie eine E-Mail an support@rigshare.app.

  • RIGSHARE_API_BASE — Überschreibt die Basis-URL der öffentlichen API. Standard ist https://www.rigshare.app/api/public/v1. Nützlich für Staging oder lokale Entwicklung.

  • RIGSHARE_AGENT_API_BASE — Überschreibt die Basis-URL der authentifizierten Agenten-API. Standard ist https://www.rigshare.app/api/v1/agent.

Claude Desktop-Konfiguration mit API-Schlüssel

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

Erforderliche Scopes für jedes authentifizierte Tool:

Tool

Mindest-Scope

rigshare_list_my_bookings

bookings:read

rigshare_list_my_sessions

sessions:read

rigshare_create_booking

bookings:write

Schlüssel können eng (schreibgeschützt) oder breit (lesen+schreiben+buchen) definiert werden, und Sie können tägliche/monatliche Budgetobergrenzen pro Schlüssel festlegen. Verwalten Sie dies unter https://www.rigshare.app/profile#api-keys.

Wie die Daten fließen

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

Keine Authentifizierung, keine Cookies, keine Benutzerkonten — der Agent liest dieselben Daten, die Sie sehen würden, wenn Sie rigshare.app öffentlich durchsuchen.

Schreiboperationen

Die drei authentifizierten Tools (rigshare_list_my_bookings, rigshare_list_my_sessions, rigshare_create_booking) erfordern einen RIGShare-API-Schlüssel, der über die Umgebungsvariable RIGSHARE_API_KEY festgelegt wird. Ohne den Schlüssel geben diese Tools einen beschreibenden Fehler zurück und nur die vier öffentlichen, schreibgeschützten Tools funktionieren.

Holen Sie sich einen API-Schlüssel unter https://www.rigshare.app/profile#api-keys oder senden Sie eine E-Mail an support@rigshare.app. Schlüssel sind mit Scopes versehen (bookings:read, bookings:write, sessions:read, sessions:write) und haben konfigurierbare tägliche/monatliche Budgetobergrenzen.

Die vollständige authentifizierte API-Oberfläche ist unter https://www.rigshare.app/openapi.json dokumentiert.

Registrierungseintrag

Dieser Server ist im offiziellen MCP-Register als io.github.RPER2001/rigshare veröffentlicht. Suchen Sie in Ihrem MCP-Client danach oder überprüfen Sie es direkt:

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

Mitwirken

Fehlerberichte + PRs sind willkommen. Dieses öffentliche Repo spiegelt den MCP-Server-Teil des RIGShare-Haupt-Monorepos wider (das für den kommerziellen Marktplatz-Code privat bleibt). Änderungen fließen bei jedem Release vom Monorepo → in dieses Repo; für Hotfixes können Sie auch direkt hier einen PR einreichen.

Lizenz

MIT. Copyright © 2026 RIGShare LLC. Kontakt: 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
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 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.

Resources

Related MCP Connectors

Related MCP Servers