Skip to main content
Glama
Sign In

EventTrader MCP

by com.cymetica
OverviewDiscussionsAdmin

Bb File Request

bb_file_request

Build it Better: file BB-REQUEST — name a financial app your human uses and what it should do BETTER; Cymetica's AI pipeline rebuilds it on EventTrader. Returns the ticket, the proposed scope (BB-SPEC, spec_text) and a one-time request_token — STORE the token, it is the only key to accept the scope and post the verdict. Filing a Build it Better request needs the Dynamic plan: you pay the measured cost of the build plus a small fee, from prepaid credit you control, with an optional monthly limit (subscribe at https://cymetica.com/usage). A Pro or Max plan you already pay for also works; the Free plan does not. No ET10 holding is needed. The 24-hour clock starts when you accept the scope. Automatic builds are read-only tools; anything that moves money is human-reviewed.

Input Schema

NameRequiredDescriptionDefault
nameNoowner name or handle
agentNoyour agent's name
emailNoowner email for the ship notice
symbolNo2-10 char ticker for the build's memecoin; a BB-prefixed one is picked when omitted
app_urlNopublic URL of the app to rebuild — on its own this is a complete request. Omit it ONLY for an app that does not exist yet (then app_name + improvements are required)
app_nameNothe app's name (read from the link when omitted); the new app's name for an idea
coin_nameNoname of that memecoin
improvementsNowhat it should do better (or, for an idea, what it should do), 12-8000 chars, one per line; with a link it may be sent later via bb_request_change

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • changedInput schema / properties / improvements / description
      Previous value: -"what it should do better (or, for an idea, what it should do), 12-1000 chars, one per line; with a link it may be sent later via bb_request_change"New value: +"what it should do better (or, for an idea, what it should do), 12-8000 chars, one per line; with a link it may be sent later via bb_request_change"
  2. First observed

TDQS

A4.4/5.0
Behavior5/5

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

Beyond the sparse annotations, the description discloses important behavior: it returns a ticket, proposed scope (BB-SPEC/spec_text), and a one-time request_token that must be stored. It also explains payment mechanics, prepaid credit, optional monthly limits, the 24-hour clock starting at scope acceptance, and that money-moving builds are human-reviewed.

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

Conciseness4/5

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

The core purpose and critical token-storage instruction are front-loaded, and the paragraph remains dense with relevant information. It is somewhat long and packs plan/payment details into the same block, but the length is largely justified by the tool's complexity.

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 complex mutation tool with no output schema, the description covers the essential context: what is returned, how the token is used, payment and plan prerequisites, timing, and human-review boundaries. Combined with full schema descriptions, an agent has enough information to file the request correctly.

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?

The input schema has 100% description coverage, so all eight parameters are already documented in structured data. The description reinforces the high-level idea of naming an app and improvements, but it adds little parameter-level detail beyond the schema, making the baseline 3 appropriate.

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 action and resource: filing a Build it Better request to have a named financial app rebuilt on EventTrader. It also distinguishes this filing step from downstream steps by explaining that the returned request_token is required to accept the scope and post the verdict.

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 the plan prerequisites: Dynamic plan, or an existing Pro/Max plan, with Free explicitly excluded, and notes that no ET10 holding is required. It does not explicitly name all alternative sibling tools such as bb_get_request or bb_search_rebuilt_apps, so the routing guidance is strong but not exhaustive.

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

All EventTrader MCP toolsInspect
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