Skip to main content
Glama
deenesjakoruzh
RPER2001

rigshare-mcp

by RPER2001
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

rigshare-mcp

RIGShare를 위한 모델 컨텍스트 프로토콜(MCP) 서버 — 모든 MCP 호환 AI 에이전트(Claude Desktop, Cursor, VS Code, 커스텀 에이전트 프레임워크)에서 건설 장비 및 로봇/AI 하드웨어 대여 목록을 탐색하세요.

기능

AI 에이전트에 7가지 도구를 제공합니다. 4개는 읽기 전용(인증 불필요), 3개는 인증 필요(RIGShare API 키 필요) 도구입니다.

읽기 전용(API 키 불필요):

도구

기능

rigshare_search_equipment

부문, 카테고리, 가격, 위치, 원격 액세스 여부별 장비 목록 조회/필터링

rigshare_get_equipment

단일 목록에 대한 상세 정보(사양, 가격, 소유자, 이미지, 딥링크 URL)

rigshare_list_categories

목록 개수가 포함된 사용 가능한 카테고리

rigshare_get_owner_onboarding

장비 소유자 모집 — 전체 제안(수수료율, 원격 액세스 도구, 보안 기능) 및 단계별 가입 안내를 반환합니다. 사용자가 대여하고 싶은 장비를 소유하고 있다고 언급하거나, 검색 결과가 없을 때(해당 카테고리에 소유자가 필요하다는 신호) 이 도구를 호출하세요.

인증 필요(적절한 범위의 RIGSHARE_API_KEY 환경 변수 필요):

도구

필수 범위

기능

rigshare_list_my_bookings

bookings:read

인증된 사용자의 RIGShare 예약 내역(장비, 날짜, 상태, 합계)

rigshare_list_my_sessions

sessions:read

활성 및 과거 원격 세션(GPU 할당, 시간, 비용)

rigshare_create_booking

bookings:write

새 예약 생성. 서버가 가격을 계산하며, 클라이언트 힌트는 무시됩니다. ID 인증, 보증금 보관, 키별 예산 한도를 적용합니다.

읽기 전용 도구는 공개 API(IP당 분당 100회 요청)를 사용합니다. 인증된 도구는 Bearer 인증을 사용하여 /api/v1/agent/* 인터페이스에 접근하며, API 키에 설정된 범위와 예산 한도를 준수합니다.

Related MCP server: hive-mcp-depin

사용 사례

ML / AI 엔지니어:

  • "이번 주말에 이용 가능한 가장 저렴한 H100을 찾아줘"

  • "지금 SSH 액세스가 가능한 A100 80GB 설정이 있나요?"

  • "RIGShare에서 추론용 GPU의 시세는 얼마인가요?"

로봇 공학 연구원:

  • "이족 보행 테스트를 위해 대여할 수 있는 휴머노이드 로봇은 무엇인가요?"

  • "하루 200달러 미만의 카메라 피드가 포함된 산업용 로봇 팔을 보여줘"

건설 계약자:

  • "텍사스에 있는 10톤 미만의 굴착기를 찾아줘"

  • "이번 주 살리나스에서 대여 가능한 가위형 리프트는 무엇인가요?"

AI 조달 에이전트:

  • "캘리포니아에서 대여 가능한 모든 3D 프린터 목록을 가격순으로 정리해서 알려줘"

장비 소유자(공급 측면 모집):

  • "사용하지 않는 Unitree G1 휴머노이드가 있는데 어떻게 대여하나요?"

  • "4x H100 장비를 소유하고 있는데, 이를 위한 마켓플레이스가 있나요?"

  • "우리 팀이 60%의 시간만 사용하는 굴착기가 3대 있습니다. 나머지를 대여할 수 있나요?"

이러한 경우 에이전트는 rigshare_get_owner_onboarding을 호출하여(장비 유형을 선택적으로 포함) 수수료율, 올바른 가입 URL, 단계별 절차, 부문별 제안(로봇/AI를 위한 원격 액세스, 건설을 위한 GPS + 보험)을 포함한 전체 제안을 반환받습니다.

설치

Claude Desktop

claude_desktop_config.json(설정 → 개발자 → 설정 편집)에 추가하세요:

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

Claude Desktop을 재시작하세요. 채팅 입력 영역의 🔌 MCP 서버 목록에 "rigshare"가 표시되어야 합니다.

Cursor

~/.cursor/mcp.json:

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

VS Code (Continue 확장 프로그램)

mcpServers 아래에 Continue 설정을 추가하세요:

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

모든 MCP 호환 에이전트 프레임워크

stdio 전송으로 실행:

npx -y rigshare-mcp

로컬 테스트

# 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

그런 다음 설정을 변경하여 MCP 클라이언트가 로컬 빌드를 가리키도록 하세요:

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

환경 변수

  • RIGSHARE_API_KEY — 선택 사항. 인증된 도구(list_my_bookings, list_my_sessions, create_booking)를 활성화합니다. 키가 없으면 해당 도구는 설명 오류를 반환합니다. https://www.rigshare.app/profile#api-keys 에서 키를 받거나 support@rigshare.app으로 이메일을 보내세요.

  • RIGSHARE_API_BASE — 공개 API 기본 URL을 재정의합니다. 기본값은 https://www.rigshare.app/api/public/v1입니다. 스테이징 또는 로컬 개발에 유용합니다.

  • RIGSHARE_AGENT_API_BASE — 인증된 에이전트 API 기본 URL을 재정의합니다. 기본값은 https://www.rigshare.app/api/v1/agent입니다.

API 키가 포함된 Claude Desktop 설정

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

각 인증된 도구에 필요한 범위:

도구

최소 범위

rigshare_list_my_bookings

bookings:read

rigshare_list_my_sessions

sessions:read

rigshare_create_booking

bookings:write

키는 좁게(읽기 전용) 또는 넓게(읽기+쓰기+예약) 범위를 지정할 수 있으며, 키별 일일/월간 예산 한도를 설정할 수 있습니다. https://www.rigshare.app/profile#api-keys 에서 관리하세요.

데이터 흐름

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

인증, 쿠키, 사용자 계정이 없으며, 에이전트는 사용자가 rigshare.app을 공개적으로 탐색할 때 보는 것과 동일한 데이터를 읽습니다.

쓰기 작업

3개의 인증된 도구(rigshare_list_my_bookings, rigshare_list_my_sessions, rigshare_create_booking)는 RIGSHARE_API_KEY 환경 변수를 통해 설정된 RIGShare API 키가 필요합니다. 키가 없으면 해당 도구는 설명 오류를 반환하며 4개의 공개 읽기 전용 도구만 작동합니다.

https://www.rigshare.app/profile#api-keys 에서 API 키를 받거나 support@rigshare.app으로 이메일을 보내세요. 키는 범위가 지정되며(bookings:read, bookings:write, sessions:read, sessions:write) 구성 가능한 일일/월간 예산 한도가 적용됩니다.

전체 인증 API 인터페이스는 https://www.rigshare.app/openapi.json 에 문서화되어 있습니다.

레지스트리 등록

이 서버는 공식 MCP 레지스트리에 io.github.RPER2001/rigshare로 게시되어 있습니다. MCP 클라이언트에서 검색하거나 직접 확인하세요:

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

기여

버그 리포트 및 PR을 환영합니다. 이 공개 저장소는 주요 RIGShare 모노레포(상업용 마켓플레이스 코드는 비공개 유지)의 MCP 서버 부분을 미러링합니다. 변경 사항은 릴리스마다 모노레포에서 이 저장소로 흐르며, 핫픽스의 경우 여기에서 직접 PR을 보낼 수도 있습니다.

라이선스

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