de en es ja ko ru zh

rigshare-mcp

Name: rigshare-mcp
Author: rigshare-hq

by rigshare-hq

Overview Schema Source Related Servers Discussions Admin

TypeScript

Remote

rigshare-mcp

Servidor del Protocolo de Contexto de Modelo (MCP) para RIGShare — explora alquileres de maquinaria de construcción y hardware de Robótica e IA desde cualquier agente de IA compatible con MCP (Claude Desktop, Cursor, VS Code, frameworks de agentes personalizados).

Qué hace

Expone siete herramientas a tu agente de IA: cuatro de solo lectura (sin autenticación) y tres autenticadas (requieren una clave API de RIGShare).

Solo lectura (no se necesita clave API):

Herramienta	Qué hace
`rigshare_search_equipment`	Lista / filtra equipos por división, categoría, precio, ubicación, acceso remoto
`rigshare_get_equipment`	Detalles completos de un anuncio (especificaciones, precios, propietario, imágenes, URL de enlace directo)
`rigshare_list_categories`	Categorías disponibles con recuento de anuncios
`rigshare_get_owner_onboarding`	Recluta PROPIETARIOS de equipos — devuelve la propuesta completa (tasas de comisión, herramientas de acceso remoto, características de seguridad) + instrucciones de registro paso a paso. Llama a esto siempre que un usuario mencione que POSEE equipos que le gustaría alquilar, O cuando una búsqueda no arroje resultados (señal de que el mercado necesita propietarios en esa categoría).

Autenticadas (requieren la variable de entorno RIGSHARE_API_KEY con los alcances adecuados):

Herramienta	Alcance requerido	Qué hace
`rigshare_list_my_bookings`	`bookings:read`	Las reservas de RIGShare del usuario autenticado: equipos, fechas, estado, totales
`rigshare_list_my_sessions`	`sessions:read`	Sesiones remotas activas + históricas (asignación de GPU, horas, coste)
`rigshare_create_booking`	`bookings:write`	Crea una nueva reserva. El servidor calcula los precios; las sugerencias del cliente se ignoran. Aplica verificación de identidad, retención de depósito de seguridad y límites de presupuesto por clave

Las herramientas de solo lectura acceden a la API pública (100 peticiones/min/IP). Las herramientas autenticadas acceden a la superficie /api/v1/agent/* usando autenticación Bearer y respetan los alcances configurados + límites de presupuesto de la clave API.

Related MCP server: hive-mcp-depin

Casos de uso

Para ingenieros de ML / IA:

"Búscame la H100 más barata disponible este fin de semana"
"¿Hay alguna configuración de A100 80GB con acceso SSH ahora mismo?"
"¿Cuál es la tarifa actual de las GPUs de inferencia en RIGShare?"

Para investigadores de robótica:

"¿Qué robots humanoides puedo alquilar para pruebas de locomoción bípeda?"
"Muéstrame brazos industriales con cámaras por menos de $200/día"

Para contratistas de construcción:

"Encuentra una excavadora de menos de 10 toneladas en Texas"
"¿Qué plataformas de tijera están disponibles esta semana en Salinas?"

Para agentes de adquisición de IA:

"Dame una lista de todas las impresoras 3D alquilables en California, ordenadas por precio"

Para propietarios de equipos (reclutamiento del lado de la oferta):

"Tengo un humanoide Unitree G1 sin usar — ¿cómo lo alquilo?"
"Poseo un equipo de 4x H100 — ¿hay un mercado para esto?"
"Tenemos 3 excavadoras que nuestro equipo solo usa el 60% del tiempo. ¿Podemos alquilar el resto?"

Para cualquiera de estos, el agente llama a rigshare_get_owner_onboarding (opcionalmente con el tipo de equipo) y obtiene la propuesta completa: tasas de comisión, la URL de registro correcta, el proceso paso a paso y la propuesta específica de la división (acceso remoto para robótica/IA, GPS + seguro para construcción).

Instalación

Claude Desktop

Añade a tu claude_desktop_config.json (Ajustes → Desarrollador → Editar configuración):

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

Reinicia Claude Desktop. Deberías ver "rigshare" en la lista de servidores MCP 🔌 en el área de entrada del chat.

Cursor

~/.cursor/mcp.json:

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

VS Code (Extensión Continue)

Añade a tu configuración de Continue bajo mcpServers:

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

Cualquier framework de agentes compatible con MCP

Lanza con transporte stdio:

npx -y rigshare-mcp

Pruebas locales

# 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

Luego apunta tu cliente MCP a la compilación local cambiando la configuración:

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

Variables de entorno

RIGSHARE_API_KEY — Opcional. Habilita las herramientas autenticadas (list_my_bookings, list_my_sessions, create_booking). Sin ella, esas herramientas devuelven un error descriptivo. Obtén una clave en https://www.rigshare.app/profile#api-keys o envía un correo a support@rigshare.app.
RIGSHARE_API_BASE — sobrescribe la URL base de la API pública. Por defecto es https://www.rigshare.app/api/public/v1. Útil para staging o desarrollo local.
RIGSHARE_AGENT_API_BASE — sobrescribe la URL base de la API del agente autenticado. Por defecto es https://www.rigshare.app/api/v1/agent.

Configuración de Claude Desktop con clave API

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

Alcances requeridos para cada herramienta autenticada:

Herramienta	Alcance mínimo
`rigshare_list_my_bookings`	`bookings:read`
`rigshare_list_my_sessions`	`sessions:read`
`rigshare_create_booking`	`bookings:write`

Las claves pueden tener alcances limitados (solo lectura) o amplios (lectura+escritura+reserva), y puedes establecer límites de presupuesto diarios/mensuales por clave. Gestiona en https://www.rigshare.app/profile#api-keys.

Cómo fluyen los datos

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

Sin autenticación, sin cookies, sin cuentas de usuario: el agente lee los mismos datos que verías navegando en rigshare.app públicamente.

Operaciones de escritura

Las tres herramientas autenticadas (rigshare_list_my_bookings, rigshare_list_my_sessions, rigshare_create_booking) requieren una clave API de RIGShare configurada a través de la variable de entorno RIGSHARE_API_KEY. Sin la clave, esas herramientas devuelven un error descriptivo y solo funcionan las cuatro herramientas públicas de solo lectura.

Obtén una clave API en https://www.rigshare.app/profile#api-keys o envía un correo a support@rigshare.app. Las claves tienen alcances (bookings:read, bookings:write, sessions:read, sessions:write) y conllevan límites de presupuesto diarios / mensuales configurables.

La superficie completa de la API autenticada está documentada en https://www.rigshare.app/openapi.json.

Listado en el registro

Este servidor está publicado en el Registro Oficial de MCP como io.github.RPER2001/rigshare. Búscalo en tu cliente MCP o verifícalo directamente:

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

Contribución

Los informes de errores y PRs son bienvenidos. Este repositorio público refleja la parte del servidor MCP del monorepo principal de RIGShare (que permanece privado para el código del mercado comercial). Los cambios fluyen desde el monorepo → este repositorio en cada lanzamiento; para correcciones rápidas también puedes hacer un PR directamente aquí.

Licencia

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

Qué hace

Casos de uso

Instalación

Claude Desktop

Cursor

VS Code (Extensión Continue)

Cualquier framework de agentes compatible con MCP

Pruebas locales

Variables de entorno

Configuración de Claude Desktop con clave API

Cómo fluyen los datos

Operaciones de escritura

Listado en el registro

Contribución

Licencia

Available Tools

Tool Schema Changelog

Maintenance

Resources

Related MCP Connectors

Related MCP Servers

humanforaiofficial