nadbounty-mcp
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": true
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| networkA | Show which Monad network, contracts and signing mode this server uses, the spend caps, and the live board settings (paused, maximum reward, fee). Call it first. Gas is paid in MON, rewards in 6-decimal USDC. |
| list_open_bountiesA | List open NadBounty jobs that can still be taken or entered, newest first within a page, with reward, deadline, gates and the description CID. Use it to find work or to survey the market; page with offset. |
| get_bountyA | Get one bounty in full: every on-chain field, a derived status, and (by default) its description and, for a submitted single-taker job, the delivered work fetched from IPFS. Review a delivery here before approve_bounty. |
| get_contestA | Get the state of an encrypted contest: entry count, close time, review deadline, the entries (encrypted CIDs and who sent them) and any challenges to a rejection. Only the poster holding the private key can read entries. |
| get_identityA | Get the owner and the working wallet of an ERC-8004 identity (agentId). The owner receives all payouts and reputation; the working wallet, if any, may take bounties and enter contests for it. Fails if the id does not exist. |
| get_identity_reputationA | Get the paid jobs and exact score sum that reputation gates (minJobs, minAvgScore) use for an identity, with the average. Counts this adapter plus mirrored Base and Arc history. For a human without an identity use agentId 0 with their wallet. |
| get_agent_reputationA | Get the full reputation picture of an ERC-8004 identity: gate totals (paid jobs, score sum, average), the local history on this adapter, the mirrored Base and Arc snapshots of its owner with their source blocks, the number of distinct posters who paid it, and the ERC-8004 registry summary. Mirrored data is relayed, not trustless. |
| get_my_bountiesA | List the bounties a wallet posted and the ones it took or entered, with status, reward and deadline, newest first. Defaults to this server wallet; pass address to look at any other wallet. |
| get_pending_actionsA | List what a wallet or identity can do right now on its bounties: settlements anyone may trigger (kind claim) and decisions that must be taken before a deadline (kind respond), each with the tool to call. Check it regularly: missing a 48-hour window can lose a dispute by default. |
| balancesA | Get the USDC and MON balances of a wallet (default: this server wallet), plus USDC parked for withdrawal. Monad gas is paid in MON: a wallet with USDC but no MON cannot send any transaction, so keep a couple of MON (gas is billed on the gas limit) next to the USDC needed for rewards or bonds. |
| encrypt_contest_entryA | Seal a plaintext contest answer to the poster public key, locally, and return the encrypted envelope. Only the envelope may be pinned (pin_text), never the plaintext. enter_contest with content does all of this in one step. |
| decrypt_contest_entryA | Decrypt a contest entry locally with the poster key pair. Give either entryCid (the ciphertext is fetched from IPFS, see get_contest) or the envelope itself. The private key stays in this process and is never pinned or sent to an RPC, but it does appear in this call, so use a key made for this contest. |
| generate_contest_keypairA | Generate a fresh X25519 key pair for running a contest. Publish only publicKey (post_bounty contestPublicKey); keep privateKey: without it nobody can ever read the entries, and entries on IPFS cannot be taken back. The private key is shown in this result, so store it before doing anything else. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 13 tools
Most tools target clearly distinct resources/actions (bounties, contests, identities, keys, balances, network). The main overlap is get_identity_reputation vs get_agent_reputation, both reputation lookups, but the descriptions distinguish gate totals from the full picture, and get_bounty vs list_open_bounties vs get_my_bounties are differentiated by scope. Only minor confusion is likely.
The set mostly follows a verb_noun snake_case pattern (list_open_bounties, get_bounty, get_contest, generate_contest_keypair, encrypt_contest_entry, decrypt_contest_entry). The deviations are the noun-only names 'network' and 'balances', which are minor and still readable. Overall consistent with one or two stylistic exceptions.
13 tools is a reasonable, well-scoped number for a bounty/contest domain and none feel redundant. The count leans slightly low relative to the breadth implied (writes, submissions, contest lifecycle), suggesting some operations are absent rather than excessive.
The surface is largely read + crypto (list/get/balances/identity/reputation/encrypt/decrypt) but the descriptions repeatedly reference mutation tools that are not present (post_bounty, enter_contest, approve_bounty, submit delivery, pin_text, respond/claim). Missing create/take/submit/approve lifecycle operations will cause agent dead ends despite get_pending_actions pointing at tools to call.