Which integrations are available for this server?

Provides on-chain Solana Mainnet escrow and token mint verification for Gibwork bounties, allowing agents to validate advertised bounty token mints and escrow parameters directly via Solana JSON-RPC.

How do I use Gibwork Sentinel?

1. Click on "Deploy Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@Gibwork Sentinel list the latest bounties paying over 50 USDC" That's it! The server will respond to your query, and you can continue using it as needed. Here is a step-by-step guide with screenshots.

Gibwork Sentinel

by TomerGamerTV

Overview Schema Source Related Servers Discussions Admin

TypeScript

Local

License: MIT TypeScript Model Context Protocol Solana

Gibwork Sentinel is a developer automation utility, interactive terminal tool, and native Model Context Protocol (MCP) Server designed to bridge the Gibwork Solana Bounty Protocol (gib.work) with autonomous AI agents (Claude, Cursor, Antigravity, OpenCode) and terminal power users.

It eliminates the friction of web-app browsing by providing automated bounty discovery, on-chain Solana escrow verification, and automated project workspace scaffolding.

🚀 Key Features

⚡ Fast Terminal CLI (gib-sentinel): Real-time filtering across active Gibwork bounties by payout amount (USDC/SOL), category, and status.
🤖 Native Model Context Protocol (MCP) Server: Enables LLM agents to autonomously discover tasks, read deliverable specifications, and verify escrow parameters via standard MCP tools.
🔒 On-Chain Solana Escrow Verification: Directly queries Solana Mainnet JSON-RPC to verify that advertised bounty token mints (e.g. SPL USDC EPjFWdd5AufqSSqeM2qN1xzybapC8G4wEGGkZwyTDt1v) exist and are valid before committing development hours.
📁 Automated Workspace Scaffolding: Automatically creates an isolated project directory with task metadata, deliverable checklists (DELIVERABLE_SPEC.md), and PR templates for any claimed bounty.

Related MCP server: bounty-mcp

📦 Installation & Setup

Prerequisites

Node.js >= 18.0.0
npm or pnpm

Global Installation (or Run with npx)

git clone https://github.com/TomerGamerTV/gibwork-sentinel.git
cd gibwork-sentinel
npm install
npm run build
npm link

🛠️ CLI Usage Guide

1. List Open Bounties

Discover all open bounties funded on Solana:

gib-sentinel list

Filter by minimum reward amount and token:

# Bounties paying >= 100 USDC
gib-sentinel list --min 100 --token USDC

# Filter by category
gib-sentinel list --category Development

Output as machine-readable JSON:

gib-sentinel list --json

2. Inspect Bounty Requirements

Fetch full requirements, deadline, and creator metadata:

gib-sentinel inspect 1052f22d-3f87-4b1d-b0d7-71a60679e7fa

3. Verify On-Chain Solana Escrow

Cross-validate the token mint and escrow contract parameters on Solana Mainnet:

gib-sentinel verify 1052f22d-3f87-4b1d-b0d7-71a60679e7fa

Sample output:

Verifying on-chain parameters for task 1052f22d-3f87-4b1d-b0d7-71a60679e7fa...

--- Solana Escrow & Mint Verification ---
Network:      Solana Mainnet-Beta
Token Mint:   EPjFWdd5AufqSSqeM2qN1xzybapC8G4wEGGkZwyTDt1v
Token Symbol: USDC
Status:       VERIFIED_ON_CHAIN
Notes:        Canonical USDC (USD Coin)
-----------------------------------------

4. Scaffold Development Workspace

Automatically scaffold an isolated deliverable environment:

gib-sentinel scaffold 1052f22d-3f87-4b1d-b0d7-71a60679e7fa

Creates:

bounty_workspaces/gibwork-developer-hackathon-bounty-1052f22d/
├── task_metadata.json
├── DELIVERABLE_SPEC.md
└── PULL_REQUEST_TEMPLATE.md

🤖 Model Context Protocol (MCP) Integration

Gibwork Sentinel exposes 4 native MCP tools for autonomous AI agents:

Tool Name	Description	Arguments
`gibwork_list_bounties`	List and filter active bounties from Gibwork	`minAmount`, `token`, `category`, `search`
`gibwork_get_bounty_details`	Get complete description and requirements	`taskId` (UUID)
`gibwork_verify_escrow`	Verify on-chain Solana mint & escrow parameters	`taskId` (UUID)
`gibwork_scaffold_workspace`	Scaffold local development directory	`taskId` (UUID), `outputDir`

Configuration for Claude Desktop / Cursor / Antigravity

Add the following to your MCP settings configuration:

{
  "mcpServers": {
    "gibwork-sentinel": {
      "command": "node",
      "args": ["/path/to/gibwork-sentinel/dist/mcp-server.js"]
    }
  }
}

🏛️ Architecture & Data Flow

+---------------------+        +-------------------------+
|   Terminal User     |        |   Autonomous AI Agent   |
|   (gib-sentinel)    |        |   (Claude / Cursor MCP) |
+----------+----------+        +------------+------------+
           |                                |
           +---------------+----------------+
                           |
                           v
              +--------------------------+
              |    Gibwork Sentinel      |
              |    Core Engine           |
              +-------------+------------+
                            |
            +---------------+---------------+
            |                               |
            v                               v
+-----------------------+       +------------------------+
|  Gibwork Explore API  |       |   Solana Mainnet RPC   |
|  (api.gib.work)       |       |   (Token Mint Verify)  |
+-----------------------+       +------------------------+

📄 License

MIT License. Authored by Tomer (@TomerGamerTV).

Available Tools

4 tools

gibwork_get_bounty_detailsA

Get full description, requirements, creator info, and deadline for a specific Gibwork bounty ID.

ParametersJSON Schema

Name	Required	Description	Default
`taskId`	Yes	The unique UUID of the Gibwork task/bounty.

TDQS

A3.6/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries the full burden of behavioral disclosure. It describes what the tool does (get details) but does not state whether it is read-only, whether authentication is required, whether any side effects occur, or any rate limits. For a simple get operation this is minimal, but the description adds no behavioral context beyond the action itself.

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 a single sentence that is front-loaded with the action and purpose. It includes no fluff or redundant details, making it efficient and easy to parse. It appropriately captures the tool's essence without over-specifying.

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 the simplicity of the tool (one parameter, no output schema, no nested objects), the description adequately covers the core functionality by listing the returned content. It does not mention error conditions or output format details, but for a straightforward get operation, these are not critical. The description is sufficiently complete for an agent to know what to expect.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the schema already documents the single parameter (taskId) with a clear description. The description does not add any new meaning beyond what the schema provides; it only echoes the idea of a specific bounty ID. Since the schema fully covers the parameter, the baseline of 3 is appropriate.

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 states a specific verb (Get) and resource (bounty details) and enumerates the content returned (full description, requirements, creator info, deadline). It clearly differentiates from sibling tools: it is for a specific bounty ID, whereas list_bounties lists multiple and verify_escrow/scaffold_workspace serve different purposes. The wording 'for a specific Gibwork bounty ID' makes the target unambiguous.

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?

The description implies that this tool should be used when you have a specific bounty ID, but it does not explicitly state when to use it over alternatives or when not to use it. There is no reference to sibling tools or exclusions, leaving the routing decision to the agent's inference. While the context is clear, it lacks explicit guidance.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

gibwork_list_bountiesA

Discover and filter live bounties on the Solana Gibwork decentralized marketplace.

ParametersJSON Schema

Name	Required	Description
`token`	No	Filter by settlement token (e.g. USDC, SOL).
`search`	No	Keyword search in bounty title and description.
`category`	No	Filter by category (e.g. Development, Design, Research).
`minAmount`	No	Filter bounties with reward greater than or equal to this amount in USD/tokens.

TDQS

A3.7/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries the full burden of behavioral disclosure. It mentions 'live' bounties but does not explicitly state that the operation is read-only or describe result shape or pagination behavior. For a simple list/filter tool this is not misleading, but it adds little beyond the tool name.

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 a single front-loaded sentence with no filler. It efficiently conveys the action, resource, and marketplace context without repeating schema details or adding irrelevant information.

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?

The tool has no required parameters, all parameters are well-described in the schema, and the intended action is clear. However, there is no output schema and no mention of response format or pagination, leaving some ambiguity about what the agent will receive.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema has 100% coverage of all four parameters, so the baseline is 3 even without extra description-level parameter guidance. The description adds no semantic detail beyond 'filter', but the schema already documents each parameter clearly.

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 a specific action ('Discover and filter') and a specific resource ('live bounties on the Solana Gibwork decentralized marketplace'). This differentiates it from sibling tools like get_bounty_details, verify_escrow, and scaffold_workspace, which target different operations.

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?

The description implies the tool is for browsing and filtering bounties, but it does not explicitly state when to use it over sibling tools or mention excluded cases. There is no when-to-use/when-not-to-use guidance, so an agent must infer usage from sibling names and context.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

gibwork_scaffold_workspaceA

Scaffold a local development directory with PR template, checklist, and metadata for a Gibwork bounty.

ParametersJSON Schema

Name	Required	Description	Default
`taskId`	Yes	The Gibwork task ID to scaffold.
`outputDir`	No	Target directory (defaults to ./bounty_workspaces).

TDQS

A3.5/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description must carry the behavioral burden. It conveys a filesystem-creating operation, but does not disclose whether existing directories are overwritten, whether outputDir is auto-created, or whether remote data is fetched before scaffolding. For a side-effecting tool this is a meaningful gap.

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?

Single sentence, front-loaded verb, and no filler. It lists the key artifacts without redundancy, making the purpose immediately scannable.

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?

The description covers the what but not the operational context: no return/output description, no mention of overwrite or prerequisite behavior, and no guidance on outputDir semantics. Adequate for a simple two-parameter tool, but with gaps around side effects.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so taskId and outputDir are already documented in the input schema. The description adds no parameter-level detail beyond the schema, so the baseline of 3 applies.

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?

States a specific verb and resource: 'Scaffold a local development directory' with concrete deliverables (PR template, checklist, metadata). This clearly distinguishes the tool from sibling listing/detail/escrow operations.

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?

Usage context is implied: this is the workspace-creation step for a Gibwork bounty, not a list/detail/verify operation. However, there is no explicit 'use when' guidance, no exclusions, and no ordering context relative to sibling tools.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

gibwork_verify_escrowA

Verify the on-chain Solana token mint and escrow parameters for a Gibwork bounty before starting work.

ParametersJSON Schema

Name	Required	Description	Default
`taskId`	Yes	The Gibwork task ID to verify.

TDQS

A3.7/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries the full burden of behavioral disclosure. It does not state whether the operation is read-only, has side effects, requires special permissions, or what the output/result format is. The description only hints at a verification action without detailing consequences.

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 a single, clear sentence that front-loads the verb and object. There is no redundant text or unnecessary detail.

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?

The tool is simple with one parameter and no output schema, but the description does not explain what the verification returns or how the result is communicated. It also doesn't mention any prerequisite (e.g., obtaining a task ID from list_bounties). These gaps reduce completeness for an agent.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema describes the sole parameter 'taskId' as 'The Gibwork task ID to verify.' with 100% coverage. The tool description adds no additional meaning beyond this, so the baseline of 3 is appropriate.

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 verifies on-chain Solana token mint and escrow parameters for a Gibwork bounty. This distinguishes it from siblings like listing bounties, getting details, or scaffolding workspace. The verb 'verify' is specific and the resource is well-defined.

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 phrase 'before starting work' provides a clear temporal context for when to use this tool. However, it does not explicitly mention alternatives or when not to use it, so it falls short of a 5 but is clearly guided.

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.

4 tool updatesv1.0.0Sep 17, 2026
- First observedgibwork_get_bounty_details
- First observedgibwork_list_bounties
- First observedgibwork_scaffold_workspace
- First observedgibwork_verify_escrow

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/5.0

Scored 2026-09-17 10:55 across 4 tools

Disambiguation5/5

Each tool targets a distinct stage of the bounty workflow: discovery, detail lookup, escrow verification, and workspace setup. There is no meaningful overlap between list, get, verify, or scaffold.

Naming Consistency5/5

All tool names follow the same gibwork_<verb>_<noun> convention: list_bounties, get_bounty_details, verify_escrow, scaffold_workspace. The pattern is uniform and predictable.

Tool Count5/5

Four tools is a tight, well-scoped set for the server's apparent purpose of safely discovering and preparing for Gibwork bounties. Each tool serves a necessary function without redundancy.

Completeness4/5

The toolset covers the full pre-work lifecycle: find bounties, inspect details, verify escrow, and scaffold a workspace. Post-submission actions like submitting or claiming work are absent, but they appear outside the server's stated scope as a pre-work sentinel.

Maintenance

ActivityMaintained

ResponsivenessNo issues

Resources

GitHub Repository

Need Help?

Related Servers

Related MCP Connectors

workprotocol A
io.github.Atlaskos
Agent work marketplace — browse jobs, claim work, deliver results, get paid in USDC.
Autonomous Agents Cryptocurrency Blockchain
2
mcp-archimedes A
io.github.archimedes-market
Discover verified deep-tech engineering bounties from any AI agent.
Autonomous Agents Developer Tools
62
Frantic A
com.gofrantic
A public bounty board where AI agents do paid work. USDC on Base, paid on accepted delivery.
Blockchain Autonomous Agents Cryptocurrency
173
AgentTrust
io.github.eamwhite1
Trustless XRPL escrow oracle for AI agents. Create jobs, verify work, release XRP/RLUSD payments.
Autonomous Agents Blockchain Finance
2

Related MCP Servers

GitAgentic MCP Serverofficial
Version Control Web3 & Decentralized Tech Agent Orchestration
gitagenticdev
F
license
Not graded
quality
D
maintenance
Enables AI models like Claude or GPT to interact with a decentralized git network, supporting repository initialization, DID generation, agent spawning, and pull requests.
Updated 4 months ago (2026-05-21 15:02 UTC)
-
bounty-mcp
Developer Tools Search RAG Systems
weiseer
A
license
A
quality
D
maintenance
Enables AI agents to find and query real-time GitHub coding bounties with built-in scam filtering, supporting listing, matching, and detailed bounty retrieval.
Updated 4 months ago (2026-06-01 09:28 UTC)
4
27 npm
Apache 2.0
gibwork-mcp-server
Blockchain Developer Tools
ranadheer-designs
F
license
Not graded
quality
C
maintenance
Enables AI assistants to search, retrieve, create, triage codebases, scaffold solutions, and validate deliverables for Gibwork bounties on Solana.
Updated 9 days ago (2026-09-10 16:16 UTC)
-
Escrow Sentinel
Blockchain Web3 & Decentralized Tech Research & Data
summerlx0416-droid
A
license
Not graded
quality
A
maintenance
Enables AI agents to discover Gibwork bounties, verify their Solana escrow accounts on-chain, rank opportunities by value, competition and deadline, diff captures over time, and export Markdown/CSV/JSON reports through four read-only MCP tools requiring no wallet or API key.
Updated 8 days ago (2026-09-12 04:33 UTC)
MIT

🚀 Key Features

📦 Installation & Setup

Prerequisites

Global Installation (or Run with npx)

🛠️ CLI Usage Guide

1. List Open Bounties

2. Inspect Bounty Requirements

3. Verify On-Chain Solana Escrow

4. Scaffold Development Workspace

🤖 Model Context Protocol (MCP) Integration

Configuration for Claude Desktop / Cursor / Antigravity

🏛️ Architecture & Data Flow

📄 License

Available Tools

Tool Schema Changelog

Maintenance

Resources

Related MCP Connectors

Related MCP Servers

GitAgentic MCP Serverofficial