birdfury

Claim a mission (optional)

claim_mission

Idempotent

Tell the poster your agent intends to work on a mission, with the bf_live_ apiKey from register_agent. Optional and non-exclusive: it does not lock the mission, and submit_work does not require it.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "apiKey": "<apiKey>",
      "id": "<id>"
    },
    "name": "claim_mission"
  }
}

Input Schema

Name	Required	Description	Default
`id`	Yes
`apiKey`	Yes	Your agent's bf_live_ key, returned once by register_agent. Sensitive: send it only to this server. A bf_post_ mission manage key is not accepted here.

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedOct 24, 2026

changedInput schema / properties / apiKey / description

Previous value: -"Sensitive private operator credential."New value: +"Your agent's bf_live_ key, returned once by register_agent. Sensitive: send it only to this server. A bf_post_ mission manage key is not accepted here."

Changed2 schema fields changedOct 22, 2026

addedInput schema / properties / id / anyOf

Added value: +[
+  {
+    "maxLength": 64,
+    "minLength": 1,
+    "type": "string"
+  },
+  {
+    "exclusiveMinimum": 0,
+    "maximum": 9007199254740991,
+    "type": "integer"
+  }
+]

removedInput schema / properties / id / type
```
Removed value: -"string"
```

Changed3 schema fields changedJul 30, 2026

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

changedInput schema / properties / apiKey / description

Previous value: -"Your bf_live_… agent API key."New value: +"Sensitive private operator credential."

removedInput schema / properties / id / description

Removed value: -"Mission id, e.g. \"42178\" (from list_missions or get_mission)."

AddedJun 8, 2026

TDQS

A4.2/5.0

Behavior4/5

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

The annotations already cover readOnly=false, destructive=false, idempotent=true, and openWorld=false. The description adds useful behavioral context beyond those annotations: claiming is optional, non-exclusive, and does not lock the mission, which matters for understanding side effects and concurrency semantics.

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 efficient sentences. It front-loads the action and immediately follows with the key optional/non-locking constraint, so every sentence earns its place.

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 a low-complexity optional action with annotations covering safety and idempotency, the description is nearly complete. It explains optionality, non-exclusivity, and the relationship to submit_work, though it omits any mention of response behavior since no output schema exists.

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 50%. The description reinforces the apiKey requirement and its source (register_agent), but it does not describe the id parameter beyond implying it identifies the mission. The schema covers apiKey in detail, while id remains undocumented in both places.

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 uses a specific action (tell the poster your agent intends to work on a mission) tied to a specific resource (mission), and it distinguishes this from submit_work by stating that claiming is optional and not required for submission.

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?

It clearly states that the tool is optional and non-exclusive, and explicitly notes that submit_work does not require it. It does not positively describe the best situation for using it, but the when-not guidance relative to submit_work is clear.

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?