Skip to main content
Glama

IMD Data Feed ($0.001 per call, half for holders)

imd_feed
Read-onlyIdempotent

Use when an agent needs IMD (imd.fun) ecosystem data: launches with status, token, v4 pool, liquidity and volume; one launch with holders and the seats that built it; every live launch token's market; the swarm's health from the IMD Watchtower; a seat's work history. Poll with since= for changes. $0.001 per call, sample=1 free. Run by NIGHTSHIFT. Pass the x402 payment as payment.

Input Schema

NameRequiredDescriptionDefault
idNolaunch number or id, or seat token id
kindNo
chainNo
limitNo
sinceNoISO time: only changes after it (polling)
beforeNo
statusNo
paymentNox402 payment: the base64 PAYMENT-SIGNATURE payload for this call's terms. Leave it out to get the terms.
endpointYeslaunches (list), launch (one, needs id), tokens, swarm, agent (one seat, needs id)
holderWalletNoThe wallet that will pay, for the holder price (50% off). Holders pay half: a paying wallet that holds 500,000+ $SHIFT (in the wallet plus staked), a NIGHT FROG or a Night Watcher gets NIGHTSHIFT house checks and reports at 50%. Fast lookup holder prices have a $0.001 minimum. Swarm Desk orders cost the full quoted price. Ask with holder=<that wallet> (MCP: holderWallet) to get the holder terms, then pay from that wallet.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • changedInput schema / properties / holderWallet / description
      Previous value: -"The wallet that will pay, for the holder price (50% off). Holders pay half: a paying wallet that holds 500,000+ $SHIFT (in the wallet plus staked), a NIGHT FROG or a Night Watcher gets NIGHTSHIFT house checks and reports at 50%. Swarm Desk orders cost the full quoted price. Ask with holder=<that wallet> (MCP: holderWallet) to get the holder terms, then pay from that wallet."New value: +"The wallet that will pay, for the holder price (50% off). Holders pay half: a paying wallet that holds 500,000+ $SHIFT (in the wallet plus staked), a NIGHT FROG or a Night Watcher gets NIGHTSHIFT house checks and reports at 50%. Fast lookup holder prices have a $0.001 minimum. Swarm Desk orders cost the full quoted price. Ask with holder=<that wallet> (MCP: holderWallet) to get the holder terms, then pay from that wallet."
  2. Changed1 schema field changed
    • changedInput schema / properties / holderWallet / description
      Previous value: -"The wallet that will pay, for the holder price (50% off). Holders pay half: a paying wallet that holds 500,000+ $SHIFT (in the wallet plus staked), a NIGHT FROG or a Night Watcher gets every NIGHTSHIFT house service at 50%. Ask with holder=<that wallet> (MCP: holderWallet) to get the holder terms, then pay from that wallet."New value: +"The wallet that will pay, for the holder price (50% off). Holders pay half: a paying wallet that holds 500,000+ $SHIFT (in the wallet plus staked), a NIGHT FROG or a Night Watcher gets NIGHTSHIFT house checks and reports at 50%. Swarm Desk orders cost the full quoted price. Ask with holder=<that wallet> (MCP: holderWallet) to get the holder terms, then pay from that wallet."
  3. Changed1 schema field changed
    • addedInput schema / properties / holderWallet
      Added value: +{
      +  "description": "The wallet that will pay, for the holder price (50% off). Holders pay half: a paying wallet that holds 500,000+ $SHIFT (in the wallet plus staked), a NIGHT FROG or a Night Watcher gets every NIGHTSHIFT house service at 50%. Ask with holder=<that wallet> (MCP: holderWallet) to get the holder terms, then pay from that wallet.",
      +  "pattern": "^0x[0-9a-fA-F]{40}$",
      +  "type": "string"
      +}
  4. Added

TDQS

A3.5/5.0
Behavior4/5

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

With readOnly/idempotent/non-destructive already declared, the description adds real context: per-call pricing, a free sample, an x402 payment handshake where omitting `payment` yields terms, and incremental polling via since=. It doesn't cover rate limits, failure modes, or result size, but the added payment and polling behavior is substantive.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The opening "Use when..." is properly front-loaded, but the middle is a semicolon-chained catalog of five endpoints that reads as a run-on and is hard to scan. Billing and payment notes trail at the end where they belong, but the whole is denser than it needs to be.

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?

For a 10-parameter, five-endpoint gateway with no output schema, the description should say at least roughly what each endpoint returns and what an error or unpaid-terms response looks like. It lists the data categories, but leaves response shape, pagination behavior and the free-sample mechanics to the caller to discover.

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 coverage is 50%: endpoint, id, payment and holderWallet are well documented in-schema, while kind, chain, before, status and limit have no description anywhere. The description only reinforces `since` (polling) and the payment pass-through, so it adds marginal meaning without compensating for the undocumented half.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

Names the resource (IMD ecosystem data) and enumerates the five data shapes it returns — launches, single launch with holders, live token markets, swarm health, seat history — which maps onto the endpoint enum. It never mentions the closely related siblings imd_market and imd_swarm, so an agent can't tell from the text why it would pick this tool over those.

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?

"Use when an agent needs IMD ecosystem data" is a broad trigger, and "Poll with since= for changes" is a genuine usage hint. But the sibling list contains imd_market, imd_swarm and imd_feed_sample, and the description offers no guidance on when to prefer those narrower tools over this multiplexed feed.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.