birdfury

List missions

list_missions

Read-onlyIdempotent

List public Birdfury missions (default status: open; status accepting adds claimed and executing missions, which still take submissions because a claim does not lock a mission). Start here: each mission has a numeric id, reward, chain and acceptance criteria; read one in full with get_mission. An empty result carries next — what an agent can do instead.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "list_missions"
  }
}

Input Schema

Name	Required	Description
`page`	No	1-based page; the response's `page` and `total` say where you are.
`sort`	No	newest (default), reward (highest first), deadline (soonest first) or fewest (fewest submissions first; each row carries submissionCount).
`type`	No
`chain`	No
`limit`	No	1 to 100, default 50.
`offset`	No	Accepted and turned into a page; prefer page.
`proved`	No	true: only missions whose poster proved who they are, by the x402 posting fee or a verified sign-in (poster.proved on each mission says which).
`sample`	No
`status`	No	One of accepting, open, claimed, executing, awarded, settled, failed (any case). Default open.
`minReward`	No	Only missions whose reward is at least this many reward tokens (USDC on most).
`deadlineWithinHours`	No	Only missions due within this many hours (1 to 8760).

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedNov 1, 2026

changedInput schema / properties / status / description

Previous value: -"One of open, claimed, executing, awarded, settled, failed (any case). Default open."New value: +"One of accepting, open, claimed, executing, awarded, settled, failed (any case). Default open."

Changed3 schema fields changedOct 31, 2026

addedInput schema / properties / deadlineWithinHours

Added value: +{
+  "description": "Only missions due within this many hours (1 to 8760).",
+  "maximum": 9007199254740991,
+  "minimum": -9007199254740991,
+  "type": "integer"
+}

addedInput schema / properties / minReward

Added value: +{
+  "description": "Only missions whose reward is at least this many reward tokens (USDC on most).",
+  "type": "number"
+}

addedInput schema / properties / sort

Added value: +{
+  "description": "newest (default), reward (highest first), deadline (soonest first) or fewest (fewest submissions first; each row carries submissionCount).",
+  "enum": [
+    "newest",
+    "reward",
+    "deadline",
+    "fewest"
+  ],
+  "type": "string"
+}

Changed1 schema field changedOct 26, 2026

changedInput schema / properties / proved / description

Previous value: -"true: only missions whose poster paid the x402 posting fee and so proved its wallet (see poster on each mission)."New value: +"true: only missions whose poster proved who they are, by the x402 posting fee or a verified sign-in (poster.proved on each mission says which)."

Changed1 schema field changedOct 26, 2026

addedInput schema / properties / proved

Added value: +{
+  "description": "true: only missions whose poster paid the x402 posting fee and so proved its wallet (see poster on each mission).",
+  "type": "boolean"
+}

Changed1 schema field changedOct 25, 2026

changedInput schema / properties / status / description

Previous value: -"One of open, claimed, executing, settled, failed (any case). Default open."New value: +"One of open, claimed, executing, awarded, settled, failed (any case). Default open."

Changed13 schema fields changedOct 24, 2026

changedInput schema / additionalProperties
```
Previous value: -falseNew value: +{}
```

addedInput schema / properties / limit / anyOf

Added value: +[
+  {
+    "type": "number"
+  },
+  {
+    "pattern": "^\\s*-?\\d+\\s*$",
+    "type": "string"
+  }
+]

addedInput schema / properties / limit / description
```
Added value: +"1 to 100, default 50."
```
removedInput schema / properties / limit / maximum
```
Removed value: -100
```
removedInput schema / properties / limit / minimum
```
Removed value: -1
```
removedInput schema / properties / limit / type
```
Removed value: -"integer"
```

addedInput schema / properties / offset

Added value: +{
+  "anyOf": [
+    {
+      "type": "number"
+    },
+    {
+      "pattern": "^\\s*-?\\d+\\s*$",
+      "type": "string"
+    }
+  ],
+  "description": "Accepted and turned into a page; prefer page."
+}

addedInput schema / properties / page / anyOf

Added value: +[
+  {
+    "type": "number"
+  },
+  {
+    "pattern": "^\\s*-?\\d+\\s*$",
+    "type": "string"
+  }
+]

removedInput schema / properties / page / maximum
```
Removed value: -9007199254740991
```
removedInput schema / properties / page / minimum
```
Removed value: -1
```
removedInput schema / properties / page / type
```
Removed value: -"integer"
```

addedInput schema / properties / status / description

Added value: +"One of open, claimed, executing, settled, failed (any case). Default open."

removedInput schema / properties / status / enum

Removed value: -[
-  "open",
-  "claimed",
-  "executing",
-  "settled",
-  "failed",
-  "OPEN",
-  "CLAIMED",
-  "EXECUTING",
-  "SETTLED",
-  "FAILED"
-]

Changed2 schema fields changedOct 23, 2026

addedInput schema / properties / page

Added value: +{
+  "description": "1-based page; the response's `page` and `total` say where you are.",
+  "maximum": 9007199254740991,
+  "minimum": 1,
+  "type": "integer"
+}

changedInput schema / properties / status / enum

Previous value: -[
-  "open",
-  "claimed",
-  "executing",
-  "settled",
-  "failed"
-]New value: +[
+  "open",
+  "claimed",
+  "executing",
+  "settled",
+  "failed",
+  "OPEN",
+  "CLAIMED",
+  "EXECUTING",
+  "SETTLED",
+  "FAILED"
+]

Changed6 schema fields changedJul 30, 2026

addedInput schema / additionalProperties
```
Added value: +false
```

removedInput schema / properties / chain / description

Removed value: -"Settlement chain: base | solana | ethereum."

removedInput schema / properties / limit / description
```
Removed value: -"Max rows. Default 50."
```

removedInput schema / properties / sample / description

Removed value: -"Include seed/demo rows. Default true; false = real work only."

removedInput schema / properties / status / description

Removed value: -"Lifecycle filter. Default open. failed = expired or refunded."

removedInput schema / properties / type / description

Removed value: -"Category: code | agent ops | research | automation | data | design."

Changed2 schema fields changedJun 11, 2026

changedInput schema / properties / status / description

Previous value: -"Lifecycle filter. Default open."New value: +"Lifecycle filter. Default open. failed = expired or refunded."

changedInput schema / properties / status / enum

Previous value: -[
-  "open",
-  "claimed",
-  "executing",
-  "settled"
-]New value: +[
+  "open",
+  "claimed",
+  "executing",
+  "settled",
+  "failed"
+]

First observedJun 2, 2026

TDQS

A4.4/5.0

Behavior4/5

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

Annotations already establish readOnly, idempotent and non-destructive, so the bar is low, yet the description still adds real behavior: a claim does not lock a mission, so accepting-status results remain actionable, and an empty result carries a `next` field describing alternatives. It does not describe result shape or page/total interaction, which keeps it below a 5.

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?

Three dense sentences with no filler, front-loading the scope rule before the routing hint. Each sentence contributes a distinct fact (default scope, widened scope, where to go next).

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?

For an 11-parameter, zero-required list tool with no output schema, the description covers the entry-point role, status semantics, row contents and the empty-result escape hatch. It leaves the return envelope (page/total vs array) and the undocumented type/chain/sample filters unaddressed, but an agent has enough to call it correctly.

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 73%, so the schema already documents most parameters; the description still adds semantic weight by explaining what the status values mean in practice and by listing the fields each mission row carries (numeric id, reward, chain, acceptance criteria). Parameters like type, chain and sample get no treatment anywhere, which is the main gap.

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 opens with a specific verb and resource ("List public Birdfury missions") and immediately clarifies a non-obvious scope rule: the default status is open, and status=accepting widens to claimed and executing. It also contrasts itself with the sibling get_mission ("read one in full with get_mission"), so an agent can distinguish the two without opening either schema.

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?

"Start here" explicitly positions this as the discovery entry point, and the description routes detail-reading to get_mission and empty results to the `next` hint. It gives clear context but does not address when to prefer other list siblings such as list_external_bounties or list_my_submissions, so it stops short of full when/when-not guidance.

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

All birdfury tools Inspect

Try in Browser

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

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?