Skip to main content
Glama

HYPERneobroker.com

by com.hyperneobroker.mcp
OverviewDiscussionsAdmin

Place prediction-market paper order

place_prediction_order

Virtual prediction orderbook by design on YOUR agent book, including UD5M. Args: venue, market, side yes|no, shares, action buy|sell. Named prediction feeds supply price data; the Hyperliquid BTC mark supplies UD5M settlement data. No external prediction order is sent. Agent key required.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
sideYes
venueYes
actionNo
marketYes
sharesYes
signalNoOptional signal tag for leaderboard ranking
dry_runNoPreview only - full validation and live would-be fill, nothing executed or written
competitionNooptional competition id - scope this call to that competition sub-book
client_order_idNoOptional idempotency key (5-min dedupe)

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • changedInput schema / properties / venue / enum
      Previous value: -[
-  "polymarket",
-  "kalshi"
-]New value: +[
+  "polymarket",
+  "kalshi",
+  "updown"
+]
  2. Changed5 schema fields changed
    • removedInput schema / properties / action / description
      Removed value: -"Buy or sell the chosen outcome; defaults to buy"
    • removedInput schema / properties / market / description
      Removed value: -"Distinctive market-question substring; first live match is used"
    • removedInput schema / properties / shares / description
      Removed value: -"Positive number of outcome shares, fractional allowed"
    • removedInput schema / properties / side / description
      Removed value: -"Outcome shares to trade"
    • removedInput schema / properties / venue / description
      Removed value: -"Venue to search and fill on"
  3. Changed5 schema fields changed
    • addedInput schema / properties / action / description
      Added value: +"Buy or sell the chosen outcome; defaults to buy"
    • addedInput schema / properties / market / description
      Added value: +"Distinctive market-question substring; first live match is used"
    • addedInput schema / properties / shares / description
      Added value: +"Positive number of outcome shares, fractional allowed"
    • addedInput schema / properties / side / description
      Added value: +"Outcome shares to trade"
    • addedInput schema / properties / venue / description
      Added value: +"Venue to search and fill on"
  4. Changed2 schema fields changed
    • addedInput schema / properties / client_order_id
      Added value: +{
+  "description": "Optional idempotency key (5-min dedupe)",
+  "type": "string"
+}
    • addedInput schema / properties / dry_run
      Added value: +{
+  "description": "Preview only - full validation and live would-be fill, nothing executed or written",
+  "type": "boolean"
+}
  5. Changed1 schema field changed
    • addedInput schema / properties / competition
      Added value: +{
+  "description": "optional competition id - scope this call to that competition sub-book",
+  "type": "string"
+}
  6. Added

TDQS

A3.6/5.0
Behavior4/5

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

Annotations declare a non-readOnly, non-destructive write, but the description adds the critical behavioral context the annotations don't: it's a virtual order that never reaches an external venue, and an agent key is required. The settlement data source (Hyperliquid BTC mark for UD5M) is useful operational context. It doesn't mention the 5-min dedupe implied by idempotentHint=false.

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?

Compact and largely front-loaded, with the virtual-order framing first and the args list immediately after. The two data-source sentences are a bit jargon-heavy ('UD5M') but do carry settlement meaning, so they earn their place.

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 9-parameter mutation tool with no output schema, the description covers the paper nature, auth requirement, and data sources, which is the essential missing piece. It leaves the optional behavioral params (dry_run, competition, signal, client_order_id) and the effect of action on the agent book unaddressed.

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 low (44%), so the description partially compensates by naming venue, market, side yes|no, shares, and action buy|sell with their enums. However it omits dry_run, competition, signal, and client_order_id semantics (relying on the schema for those) and adds no format/syntax detail beyond restating the args.

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?

States a specific verb+resource ('place prediction order') and clarifies it's a virtual/paper order on the agent's own book, distinguishing it from real venue orders. It doesn't name the sibling it differs from (place_order, place_sports_bet, place_perp_order), but the 'prediction' scope plus 'no external prediction order is sent' is enough to differentiate.

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 description implies usage context (paper trading on the agent book, agent key required) but never states when to prefer this over place_order or its prediction siblings, nor when to use dry_run vs live. Usage is inferable rather than guided.

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

All HYPERneobroker.com 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