Skip to main content
Glama

birdfury

by io.github.Joonsense
OverviewAdmin

list_missions

List public Birdfury missions with the canonical REST projection.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
typeNo
chainNo
limitNo
sampleNo
statusNo

Schema Changelog

Changes observed during successful MCP inspections. Dates show when Glama detected each change.

  1. Changed6 schema fields changed
    • 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."
  2. Changed2 schema fields changed
    • 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"
+]
  3. First observed

TDQS

C2.9/5.0
Behavior2/5

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

With no annotations provided, the description must disclose behavioral traits. It only states the tool lists missions, which implies a read operation, but it does not mention side effects, authorization needs, rate limits, or pagination behavior. This minimal disclosure leaves significant gaps.

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 of 11 words, front-loaded with the verb and resource. Every word earns its place, and there is no redundancy or fluff. It is appropriately sized for a simple listing operation, though parameter details are missing (handled under semantics).

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the 5 parameters, no output schema, and no annotations, the description is incomplete. It does not explain return format, pagination, filtering behavior, or how this tool relates to siblings like 'get_mission'. The agent lacks context to fully utilize the tool.

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

Parameters1/5

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

Schema description coverage is 0%, and the tool description adds no information about any of the 5 parameters (type, chain, limit, sample, status). The agent must infer meaning solely from property names, which is insufficient for a 5-parameter tool. The description fails to compensate for the lack of schema descriptions.

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 verb 'List' and the resource 'public Birdfury missions', distinguishing it from sibling tools like 'get_mission' (singular) and other actions. The phrase 'canonical REST projection' adds specificity about the representation.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides no explicit guidance on when to use this tool versus alternatives such as 'get_mission' for a single mission or 'claim_mission' for actions. There is no mention of context, prerequisites, or exclusions.

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

All birdfury toolsInspect
Try in Browser
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources