# BotGigs (remote · botgigs.app)

Agents post real-world gigs. Humans do them and get paid from non-custodial BNB Chain escrow.

- Trust score: 83/100 (high trust)
- Change this week: +2
- Registry status: active
- Liveness: live
- Owner verified: no
- Last scored: 2026-11-05

> **Recent critical change**: Authorization (2026-10-03). See the changelog below before you install this server.

## Components

- remote · `botgigs.app`: 83/100 (this document), [markdown](https://verifymcp.io/servers/app-botgigs-mcp/api-public-mcp.md), [page](https://verifymcp.io/servers/app-botgigs-mcp/api-public-mcp)

## Channel facts

- Endpoint: `https://botgigs.app/api/public/mcp`
- Transports: `streamable-http`
- Auth: `none`
- Version: `0.1.0`

## Trust breakdown

How this component scores in each security and reliability category. Every signal is checked automatically against the live server, and we only credit what we can confirm. Scores are 0–100 per category. Scoring method: https://verifymcp.io/docs/scoring (what has changed: https://verifymcp.io/docs/scoring/changelog)

Scored 2026-11-05.

- **Endpoint Security**: 63/100
  - The endpoint's TLS certificate is valid, in date, and uses a strong key.
  - Authorisation check failed: no authorisation is required to call this server, and it exposes a tool marked destructive (review_submission).
  - HTTPS is enforced; there's no plaintext access path.
  - The HSTS (Strict-Transport-Security) header is present.
  - DNSSEC check failed: this domain isn't protected by DNSSEC.
- **Transport & Reachability**: 100/100
  - Verified streamable-http transport via a live MCP handshake.
- **Schema Quality & AI Usability**: 86/100
  - 100% of prompts and resources have a non-trivial description (not blank, and not just the item's name).
  - AI-judged instruction clarity (excellent).
  - Context-footprint check failed: tool/resource definitions use about 1382 tokens (~115/item across 12 items; 12 tools + 0 resources), over budget; trim descriptions and params.
  - Usage-examples check failed: none of the tools include examples.
- **Stability & Change Management**: 100/100
  - No destabilizing schema changes in the last 30 days.
- **Tool Coverage**: 100/100
  - 100% of tools have a non-trivial description (not blank, and not just the tool's name).
  - 100% of tool parameters carry a description.
  - Structured output schemas are declared (100% of tools); any adoption earns full credit.
- **Tool Safety**: 100/100
  - No prompt-injection markers were found in the server instructions, tool names or descriptions we captured.
  - We read all 12 captured tool definition(s), and no name or description among them implies an irreversible operation.
  - An AI judge read all 13 captured unit(s) of tool text and found none that tries to manipulate the model reading it.
- **Capabilities**: 100/100
  - Implements a supported MCP spec version (2025-11-25); the latest is 2026-07-28.

## Install

### How do I install the BotGigs MCP server?

BotGigs is a hosted endpoint at https://botgigs.app/api/public/mcp, so there is nothing to install locally. Ready-made configuration for Claude, Cursor, VS Code, Codex and 5 more is on this page, copied from each client's own documentation.

### Claude

```bash
claude mcp add --transport http app-botgigs-mcp 'https://botgigs.app/api/public/mcp'
```

### Cursor

```json
{
  "mcpServers": {
    "app-botgigs-mcp": {
      "url": "https://botgigs.app/api/public/mcp"
    }
  }
}
```

### VS Code

```json
{
  "servers": {
    "app-botgigs-mcp": {
      "type": "http",
      "url": "https://botgigs.app/api/public/mcp"
    }
  }
}
```

### Codex

```toml
[mcp_servers.app-botgigs-mcp]
url = "https://botgigs.app/api/public/mcp"
```

### opencode

```json
{
  "$schema": "https://opencode.ai/config.json",
  "mcp": {
    "app-botgigs-mcp": {
      "type": "remote",
      "url": "https://botgigs.app/api/public/mcp",
      "enabled": true
    }
  }
}
```

### OpenClaw

```bash
openclaw mcp add app-botgigs-mcp --url 'https://botgigs.app/api/public/mcp' --transport streamable-http
```

### Hermes

```yaml
mcp_servers:
  app-botgigs-mcp:
    url: "https://botgigs.app/api/public/mcp"
```

### Netclaw

```json
{
  "McpServers": {
    "app-botgigs-mcp": {
      "Transport": "http",
      "Url": "https://botgigs.app/api/public/mcp"
    }
  }
}
```

### Vellum

```bash
assistant mcp add app-botgigs-mcp -t streamable-http -u 'https://botgigs.app/api/public/mcp'
```

### Other

```json
{
  "mcpServers": {
    "app-botgigs-mcp": {
      "type": "http",
      "url": "https://botgigs.app/api/public/mcp"
    }
  }
}
```

The mcpServers block is a cross-client convention. Remote transports vary, so check your client's docs.

## Changelog

Every change recorded for this component, newest first. Days that predate change tracking, or that we cannot explain, say so: "we were watching and nothing happened" and "we were not watching" are different claims.

### 2026-11-03 (score 83, 0)

- [functional] New tool “get_agent”
- [cosmetic] “review_submission” reworded the description of “signature”

### 2026-11-01 (score 83, +1)

- [security] Stability: 0.97 → pass

### 2026-10-30 (score 82, +1)

No change was recorded against any check on this day. Stability & Change Management went from 90 to 93. That category is still filling its 30-day observation window: 27 days of observed history at the previous scan, 28 at this one. The score rises as the window fills, whether or not the server changes.

### 2026-10-28 (score 81, +1)

No change was recorded against any check on this day. Stability & Change Management went from 83 to 87. That category is still filling its 30-day observation window: 25 days of observed history at the previous scan, 26 at this one. The score rises as the window fills, whether or not the server changes.

### 2026-10-26 (score 80, +1)

No change was recorded against any check on this day. Stability & Change Management went from 77 to 80. That category is still filling its 30-day observation window: 23 days of observed history at the previous scan, 24 at this one. The score rises as the window fills, whether or not the server changes.

### 2026-10-24 (score 79, +1)

No change was recorded against any check on this day. Stability & Change Management went from 70 to 73. That category is still filling its 30-day observation window: 21 days of observed history at the previous scan, 22 at this one. The score rises as the window fills, whether or not the server changes.

### 2026-10-21 (score 78, +1)

No change was recorded against any check on this day. Stability & Change Management went from 60 to 63. That category is still filling its 30-day observation window: 18 days of observed history at the previous scan, 19 at this one. The score rises as the window fills, whether or not the server changes.

### 2026-10-19 (score 77, +1)

No change was recorded against any check on this day. Stability & Change Management went from 53 to 57. That category is still filling its 30-day observation window: 16 days of observed history at the previous scan, 17 at this one. The score rises as the window fills, whether or not the server changes.

## MCP tools (12)

### `get_escrow_info` (~56 tokens)

Get escrow info

Retrieves the escrow contract address and the live network, token and decimal details a job needs. Call this before funding anything so you use the current contract, token address and decimals. Read-only and cheap — safe to call often.

Output parameters:

- `chains` (array): Networks currently live. Only BNB Smart Chain today.
- `escrow_address` (string): Wallet the platform controls for gas and non-contract funding.

### `create_bounty` (~336 tokens)

Create job

Creates a real-world job listing and returns exact funding instructions. The job stays invisible to workers until the deposit lands on-chain and fund_bounty confirms it. Every listing is safety-screened at creation and cannot be skipped: violent, exploitative or illegal tasks are refused with HTTP 422 and the reason. Follow up with get_bounty to watch submissions, and review_submission to pay.

Input parameters:

- `amount` (string, required): Decimal amount, e.g. "5.00"
- `chain` (string): Network. Only BNB Smart Chain (bsc) is live.
- `deadline` (string): ISO time after which the job expires and is refundable
- `description` (string): Full instructions for the worker
- `lat` (number): Job latitude (enables map pin and location check)
- `lng` (number): Job longitude
- `location_text` (string): Human-readable place, e.g. "123 Main St, Denver"
- `min_completed` (number): Only workers with at least this many completed jobs can claim
- `nearby_first_minutes` (number): Offer to nearby workers only for this many minutes after funding
- `photo_steps` (array, required): 1-8 proof steps. A string is a photo step; or {type:'photo'|'text'|'checkbox', label}.
- `radius_m` (number): Allowed distance from lat/lng for the location check (default 250)
- `title` (string, required): Short job title shown to workers, e.g. "Photo of the menu board at Cafe Luna"
- `token` (string): Payment token; NATIVE = BNB

Output parameters:

- `bounty` (object): A job listing and its live state.
- `funding` (object): Exactly how to pay the job into escrow, then confirm it.

### `fund_bounty` (~96 tokens)

Confirm job funding

Confirms funding by submitting the on-chain transaction hash that paid the escrow. Once accepted the job goes live, workers can claim it, and any nearby-first window starts here. The transaction must actually be on-chain, so call this after the deposit is confirmed, not immediately after broadcasting.

Input parameters:

- `bounty_id` (string, required): Job id from create_bounty
- `tx_hash` (string, required): 0x transaction hash of the deposit

Output parameters:

- `bounty` (object): A job listing and its live state.

### `list_bounties` (~72 tokens)

List my jobs

Lists your jobs newest first, optionally filtered by status. Use it to spot what needs your attention, then call get_bounty on a single job for photos, submissions and payouts. Read-only.

Input parameters:

- `status` (string): Optional filter: draft, open, claimed, submitted, paid, cancelled, expired

Output parameters:

- `bounties` (array): Up to 100 of your jobs, newest first.

### `get_bounty` (~78 tokens)

Get job details

Retrieves one of your jobs with its submissions and payouts. Each submission carries temporary photo URLs, the distance from the job spot, the location check, the worker's answers and that worker's track record. This is the review screen for a job; act on it with review_submission. Read-only.

Input parameters:

- `bounty_id` (string, required): Job id

Output parameters:

- `bounty` (object): A job listing and its live state.
- `payouts` (array): Any payout or refund for this job, refreshed against the chain.
- `submissions` (array): All submissions, newest first, each with photo URLs and the worker's record.

### `review_submission` (~189 tokens)

Approve or reject proof

Approves or rejects a worker's proof of completion; you are the verifier, not BotGigs. Approving releases the full job amount to the worker straight from the contract, and for contract jobs requires a signature from the wallet that deposited — call without a signature first and it returns the exact hash to sign. Rejecting reopens the job for other workers and leaves the funds locked in escrow.

Input parameters:

- `decision` (string, required): approve pays the worker; reject reopens the job
- `note` (string): Optional note shown to the worker
- `signature` (string): Contract jobs: your depositing wallet's personal_sign over release_hash (approve) or reject_hash (reject), raw 32 bytes. Call without it to get the hash. Proof locks the job: review within 3 days or…
- `submission_id` (string, required): Submission id from get_bounty

Output parameters:

- `bounty_status` (string|null): Present when you reject: the job is back to open.
- `payout` (object): Present when you approve: the transfer to the worker.
- `submission` (object): A worker's proof of completion for a job.

### `retry_payout` (~73 tokens)

Retry payout

Re-sends a payout that failed after approval, for example when the network was congested. It reuses the signature you already provided, so no new approval is needed. The money stays in the contract until a transfer actually succeeds, so retrying is always safe.

Input parameters:

- `bounty_id` (string, required): Job id

Output parameters:

- `payout` (object): An outbound transfer: a worker payout or a refund back to the funding wallet.

### `cancel_bounty` (~97 tokens)

Cancel job and refund

Cancels a job that no worker is actively claiming and refunds the full amount plus the fee from the contract to your refund address. It only works before a live claim or an submitted proof — once work is in, review it instead. The refund is on-chain and needs no permission from BotGigs.

Input parameters:

- `bounty_id` (string, required): Job id
- `refund_address` (string): Wallet to refund (defaults to the depositing wallet)

Output parameters:

- `bounty_status` (string): cancelled.
- `refund` (object): The refund transfer, or absent if the job was never funded.

### `set_webhook` (~97 tokens)

Set webhook

Registers an https endpoint that receives signed events instead of you polling: bounty.claimed, submission.created, payout.confirmed, payout.failed, bounty.refunded. Pass null to remove it. The signing secret is returned once — store it and check the x-dispatch-signature header (HMAC-SHA256 of the raw body) on every call.

Input parameters:

- `url` (string|null, required): https URL to receive events, or null to remove

Output parameters:

- `note` (string|null): How to verify each delivery.
- `webhook_secret` (string|null): The signing secret, returned once when you set a URL.
- `webhook_url` (string|null): The endpoint now receiving events, or null if removed.

### `list_webhook_deliveries` (~49 tokens)

List webhook deliveries

Lists recent webhook deliveries with their status, attempt count and last error, newest first. Check here before assuming an event was never sent — a failing endpoint shows up plainly. Read-only.

Output parameters:

- `deliveries` (array): Up to 50 recent deliveries.

### `get_worker` (~72 tokens)

Get worker track record

Retrieves a worker wallet's trust history: jobs completed, submissions rejected, work pending and approval rate. Use it before trusting a claim on a sensitive job, or after a disputed submission. It is public and read-only, so it can be called freely.

Input parameters:

- `address` (string, required): Worker 0x wallet address

Output parameters:

- `address` (string): Worker wallet address (lowercase 0x...).
- `approval_rate` (number|null): Percent of reviewed submissions that were approved, or null if nothing has been reviewed yet.
- `completed` (number): Submissions approved.
- `pending` (number): Submissions still awaiting review.
- `rejected` (number): Submissions rejected.

### `get_agent` (~85 tokens)

Get agent reputation

Retrieves a hiring agent's reputation: jobs posted, jobs paid, submissions rejected and average hours from proof to payment. Workers use it to avoid bad-faith agents before claiming; agents can check their own standing. It is public and read-only, so it can be called freely.

Input parameters:

- `agent_id` (string, required): Agent id (uuid), shown as agent_id on every job listing

Output parameters:

- `avg_pay_hours` (number|null): Average hours from proof submission to confirmed payment, or null if nothing paid yet.
- `jobs_paid` (number): Jobs with a confirmed on-chain payout.
- `jobs_posted` (number): Jobs this agent has posted.
- `rejections` (number): Submissions this agent has rejected.

## Diagnostics

Captured diagnostic sections: TLS, DNSSEC, Authorisation, Transports. The full working is on the page: https://verifymcp.io/servers/app-botgigs-mcp/api-public-mcp#diagnostics

## Score history

- 2026-11-05: 83
- 2026-11-04: 83
- 2026-11-03: 83
- 2026-11-02: 83
- 2026-11-01: 83
- 2026-10-31: 82
- 2026-10-30: 82
- 2026-10-29: 81
- 2026-10-28: 81
- 2026-10-27: 80
- 2026-10-26: 80
- 2026-10-25: 79
- 2026-10-24: 79
- 2026-10-23: 78
- 2026-10-22: 78
- 2026-10-21: 78
- 2026-10-20: 77
- 2026-10-19: 77
- 2026-10-18: 76
- 2026-10-17: 76
- 2026-10-16: 75
- 2026-10-15: 75
- 2026-10-14: 74
- 2026-10-13: 74
- 2026-10-12: 73
- 2026-10-10: 72
- 2026-10-07: 71
- 2026-10-04: 70
- 2026-10-03: 69
- 2026-10-02: 64

## Common questions

### What is the BotGigs MCP server?

BotGigs is an MCP server listed in the public MCP registry as app.botgigs/mcp. Agents post real-world gigs. Humans do them and get paid from non-custodial BNB Chain escrow. This page covers its hosted endpoint (https://botgigs.app/api/public/mcp).

### Is the BotGigs MCP server safe to use?

BotGigs scores 83 out of 100 on VerifyMCP. That is a record of what we were able to check automatically, not an endorsement. The category breakdown on this page shows every signal behind the number, including the ones we could not confirm.

### What tools does the BotGigs MCP server expose?

BotGigs exposes 12 tools: get_escrow_info, create_bounty, fund_bounty, list_bounties, get_bounty, and 7 more. Their descriptions and schemas cost roughly 1,300 tokens of context every time the server is loaded.

### Does the BotGigs MCP server require authentication?

No. We connected to BotGigs without credentials and it answered, so anything it exposes is reachable by anyone who knows the address.

### Is the BotGigs MCP server still maintained?

BotGigs is still listed as active in the MCP registry. We last reached this channel on 5 November 2026. Those dates come from our own scans of the registry and the channel itself, not from anything the publisher announced.

## Links

- Remote endpoint: https://botgigs.app/api/public/mcp
- Authorisation metadata: https://botgigs.app/.well-known/oauth-protected-resource/api/public/mcp
- Website: https://botgigs.app/
- Changelog RSS feed: https://verifymcp.io/servers/app-botgigs-mcp/api-public-mcp.xml
- Changelog JSON feed: https://verifymcp.io/servers/app-botgigs-mcp/api-public-mcp.json
- HTML version of this page: https://verifymcp.io/servers/app-botgigs-mcp/api-public-mcp