Skip to main content
Glama
mhr2027r-dotcom

Capital Flow Desk — UnlockFlow MCP

by mhr2027r-dotcom
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

Capital Flow Desk — MCP UnlockFlow (thin)

Thin stdio MCP server that exposes UnlockFlowEvent v1 tools for directory / host listing readiness.

Product: CFD Agent Feed (SKU B) sample surface
Schema: UnlockFlowEvent schema_version: "1" (copied from ../agent-feed/schema.json)
Status: Local illustrative seeds only — not a live authenticated feed
NFA: Research framing. Not financial advice. Do not convert sell_pressure_score into trade instructions.

What it is

Wedge

Supply shock → capital-flow judgment (calendar is input; realized flow is the read)

Transport

stdio (MCP host launches this process)

Data

data/events.json — illustrative ENA + ZRO events (illustrative: true)

Schema tool

data/unlock-flow-event.schema.json

This package is for MCP directory listing / host wiring demos. Live Agent Feed pull + Pro webhook stay behind onboarding — no API tokens in this repo.

Related MCP server: hashlock-mcp

Tools

Tool

Args

Returns

list_unlock_events

asset?, horizon?

Local UnlockFlowEvent[] (+ count / NFA note)

get_unlock_event

event_id

One UnlockFlowEvent

get_schema

—

UnlockFlowEvent JSON Schema v1

Horizons: T-30 · T-7 · T-48h · T0 · T+7.

Seed ids:

  • uf_20261005_ena_t30 — Ethena original-investor acceleration (size estimate)

  • uf_20260920_zro_t48h — LayerZero digest cliff window (estimate labels)

Always surface disclaimer: "NFA" and respect precision_grade / illustrative.

Run locally (stdio)

Requires Node.js ≥ 20.

cd /workspace/crypto-research-desk/mcp-unlockflow
npm install
npm start

npm start runs npx tsx src/index.ts and speaks MCP over stdin/stdout (log only on stderr).

Cursor / Claude Desktop style config

Repo-root .mcp.json (Open Plugins / cursor.directory auto-detect):

{
  "mcpServers": {
    "cfd-unlockflow": {
      "command": "npx",
      "args": ["-y", "tsx", "src/index.ts"]
    }
  }
}

Paste the same block into Cursor Settings → MCP / Claude Desktop mcpServers, or clone this repo and point the host at it.

After npm publish (@capitalflowdesk/mcp-unlockflow):

{
  "mcpServers": {
    "cfd-unlockflow": {
      "command": "npx",
      "args": ["-y", "@capitalflowdesk/mcp-unlockflow"]
    }
  }
}

Or after local npm install:

npm run start

Optional smoke with Inspector (host launches the process):

npx @modelcontextprotocol/inspector npx tsx src/index.ts

Pricing (draft Agent Feed)

Tier

Price

Includes (draft)

Starter

99 USDT / mo

Authenticated UnlockFlowEvent pull; schema-stable v1

Pro

299 USDT / mo

Starter + webhook (cfd.unlock_flow.v1) on publish / horizon refresh

Settlement: USDT TRC-20 · wallet in ../PRODUCTS.md
Onboard: @CapitalFlowDeskBot or @Mohammad_GNA — subject Agent Feed / UnlockFlowEvent.

Human Telegram membership is a separate SKU — do not paste Members invite links here.

Registry metadata

server.json is a draft for Official MCP Registry readiness. Do not publish until namespace ownership and packaging are intentional.

Layout

mcp-unlockflow/
  .mcp.json            # cursor.directory / Open Plugins auto-detect
  README.md
  package.json
  server.json          # registry draft — do not publish until intentional
  bin/cfd-mcp-unlockflow.js
  src/index.ts         # stdio MCP
  scripts/publish-npm.sh
  data/
    events.json        # ENA + ZRO illustrative seeds
    unlock-flow-event.schema.json

Deps: @modelcontextprotocol/sdk, zod, tsx.

Not financial advice.

Smoke test

cd mcp-unlockflow && npx tsx scripts/smoke.ts

Expect SMOKE_PASS and tools: list_unlock_events, get_unlock_event, get_schema.

Install (Cursor / Claude Desktop / cursor.directory)

  1. cursor.directory — open https://cursor.directory/plugins/new → paste
    https://github.com/mhr2027r-dotcom/mcp-unlockflow
    Auto-detect uses repo-root .mcp.json.

  2. Manual host config (same payload as .mcp.json):

{
  "mcpServers": {
    "cfd-unlockflow": {
      "command": "npx",
      "args": ["-y", "tsx", "src/index.ts"]
    }
  }
}

Run from a clone of this repo (host cwd = repo root), or after publish:

{
  "mcpServers": {
    "cfd-unlockflow": {
      "command": "npx",
      "args": ["-y", "@capitalflowdesk/mcp-unlockflow"]
    }
  }
}

Clone: git clone https://github.com/mhr2027r-dotcom/mcp-unlockflow.git

Live Agent Feed (paid)

Illustrative seeds only in this repo. Live UnlockFlow feed after USDT TRC-20 onboard:

NFA.

Available Tools

3 tools
get_schemaA

Return UnlockFlowEvent JSON Schema v1 (schema_version "1").

ParametersJSON Schema
NameRequiredDescriptionDefault

No parameters

TDQS

A4.3/5.0
Behavior3/5

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

No annotations are provided, so the description carries the burden. It states only that it 'Return[s]' a schema, which implies a read-only, side-effect-free operation but does not explicitly state this. It does not mention any error conditions, authentication, or version nuances beyond the name. For such a trivial tool, this is adequate but minimal.

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 entire description is a single, focused sentence that front-loads the action and the resource. Every word earns its place, with no filler or redundancy.

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

Completeness5/5

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

For a tool with no parameters and no output schema, the description provides everything needed to call it correctly. It states what is returned (the schema) and its version. There are no hidden requirements or unexplained behaviors. An agent can invoke this tool confidently with no further context.

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?

There are zero parameters, so according to the rubric the baseline is 4. The description adds no parameter-specific detail because none exist; the schema already reflects an empty parameter set. No compensation is needed.

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 states a specific verb ('Return') and a precise resource ('UnlockFlowEvent JSON Schema v1') with version info. It clearly distinguishes from siblings (list_unlock_events, get_unlock_event) by focusing on the schema itself rather than event instances.

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?

While it does not explicitly mention alternatives or when not to use it, the context is clear: this tool is for retrieving the schema, not for listing or fetching actual events. For a zero-parameter getter, the purpose itself provides enough usage guidance, though it lacks an explicit exclusion.

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

get_unlock_eventA

Fetch one UnlockFlowEvent by event_id from local illustrative seeds.

ParametersJSON Schema
NameRequiredDescriptionDefault
event_idYesStable event id, e.g. uf_20261005_ena_t30

TDQS

A3.8/5.0
Behavior3/5

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

With no annotations provided, the description carries the full burden. It usefully discloses that the data comes from 'local illustrative seeds,' implying a limited demo dataset and a read-only operation. It does not mention missing-ID behavior, return format, or whether the data is static, so some transparency gap remains.

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, front-loaded sentence with no filler. It conveys the action, target, key, and data source efficiently, earning its place entirely.

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 single-parameter read operation, the description covers the purpose, the required identifier, and the data source. The absence of an output schema means return details are not spelled out, but the tool name and description make clear that an UnlockFlowEvent is returned; the only minor omissions are error behavior and explicit sibling guidance.

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 100%, and the schema already documents event_id with a concrete example. The description only names the parameter without adding new semantic detail, so it stays at the baseline for high schema coverage.

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 states a specific verb ('Fetch'), a specific resource ('one UnlockFlowEvent'), and the lookup key ('by event_id'). It clearly differentiates from the sibling list_unlock_events, since it targets a single item rather than a collection.

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?

The use case is implied: use this tool when you have a specific event_id and need one event, while list_unlock_events is the likely alternative for fetching multiple events. However, the description never explicitly names this sibling or states when not to use the tool.

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

list_unlock_eventsA

List local UnlockFlowEvent v1 samples (illustrative). Optional filters: asset ticker, horizon. Seeds have illustrative:true — NFA, not live Agent Feed. Live feed: @CapitalFlowDeskBot / @Mohammad_GNA (99/299 USDT TRC-20).

ParametersJSON Schema
NameRequiredDescriptionDefault
assetNoOptional ticker filter, e.g. ENA or ZRO (case-insensitive)
horizonNoOptional horizon: T-30 | T-7 | T-48h | T0 | T+7

TDQS

A4/5.0
Behavior4/5

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

With no annotations, the description carries the burden, and it uses 'local,' 'illustrative,' 'NFA,' and 'not live Agent Feed' to disclose that the data is seeded/non-authoritative rather than real-time. It does not detail response shape or side effects, but this is a read-oriented list operation and the most important behavioral caveat is clearly stated.

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 main statement is front-loaded and brief, but the last sentence about the bot handle and '99/299 USDT TRC-20' introduces payment details that are not necessary for selecting or invoking the tool. The phrase 'seeds have illustrative:true' also partially duplicates 'illustrative.'

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 simple list call with two fully documented optional params and no required inputs, the description covers purpose, filter availability, and data provenance. There is no output schema, but the behavior is simple enough that an agent can invoke the tool without more context.

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 100%, and the schema already documents both optional filters, enums, and case-insensitivity. The description only restates 'asset ticker, horizon' as optional filters, adding no new semantics.

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 opening verb 'List' plus object 'local UnlockFlowEvent v1 samples' clearly states the operation and resource, and the parenthetical 'illustrative' immediately signals this is not a live-data tool. It is distinguishable from sibling get_unlock_event (list vs single event) and get_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?

The description says the seeds are illustrative and 'not live Agent Feed,' and points to a live-feed source, so an agent knows when this list is appropriate for sample data versus when to go external. It does not explicitly address sibling get_unlock_event, but the list-vs-get distinction is straightforward.

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

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

  1. 3 tool updatesv0.1.0
    • First observedget_schema
    • First observedget_unlock_event
    • First observedlist_unlock_events
Deploy Server
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

TDQS

A4.2/5.0

Scored across 3 tools

Disambiguation5/5

Each tool has a distinct purpose: listing events, fetching a single event by ID, and retrieving the schema. There is no overlap or ambiguity between them.

Naming Consistency5/5

All tool names follow a consistent verb_noun pattern: list_unlock_events, get_unlock_event, and get_schema. The naming is predictable and easy to infer.

Tool Count5/5

Three tools is appropriate for a server scoped to illustrative local samples. Each tool earns its place: list, get, and schema introspection.

Completeness5/5

For the stated purpose of accessing local illustrative UnlockFlowEvent v1 samples, the surface is complete: list, fetch by ID, and schema retrieval cover all necessary read-only operations. Live feed and mutation tools are explicitly out of scope.

Maintenance

ActivityMaintained
ResponsivenessNo issues

Resources

Related MCP Connectors

Related MCP Servers