Skip to main content
Glama

get_engine_feed

Read-onlyIdempotent

The Coil Live engine feed: every name with the per-name fields a disciplined entry needs, its structural stop and target with their basis, risk-reward, buy score, conviction and entry lane, plus the candidates the rulebook would act on now (an empty list is the discipline working). It is the board Coil's engine starts from, a superset of the complete live board that also carries the leveraged vehicle and ladder placement (engine_fields, including coil_score / coil_kind). Optional symbols[] filter. Size, measured on ~800 names: unfiltered ≈1.35 MB (hundreds of thousands of tokens); a 2-name symbols read ≈70 KB; the same read with compact=true ≈12 KB; compact=true for the whole board ≈350 KB. Optional fields[] picks engine fields; limit and cursor page the names by symbol. Refreshed about every 5 minutes in market hours; identical for every subscriber; research, not advice. Engine fields are self-described in the payload's schema block (key · tier · description · since; omitted when compact=true). dip: {ok, codes, setup}: present only for oversold-pullback candidates; a dip buy only on a completed hourly turn above the entry-quality and depth floors. Coil Live is a subscription with a 7-day free trial; subscribers connect the Coil Live connector and sign in, and this read returns live data.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "get_engine_feed"
  }
}

Input Schema

NameRequiredDescriptionDefault
limitNoOptional: page size, names per page (sorted by symbol). The response carries page.next_cursor.
cursorNoOptional: the page.next_cursor from the previous page (the last symbol returned). Omit for the first page.
fieldsNoOptional: keep only these engine_fields keys per name (e.g. ["stop","target","rr"]). Unknown keys are echoed in unknown_fields. With compact=true this replaces the core engine-field set.
compactNoOptional, default false (the full payload, unchanged). true = core fields only: names[] and engine_fields[] keep the core keys, and the fixed context blocks (schema, rotation, awareness, perf, pair_rotation, books beyond regime, day rows/cohorts) are dropped. candidates[], freshness and rules_version always ride.
symbolsNoOptional: trim names + engine_fields to these tickers (max 50)

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed4 schema fields changed
    • addedInput schema / properties / compact
      Added value: +{
      +  "description": "Optional, default false (the full payload, unchanged). true = core fields only: names[] and engine_fields[] keep the core keys, and the fixed context blocks (schema, rotation, awareness, perf, pair_rotation, books beyond regime, day rows/cohorts) are dropped. candidates[], freshness and rules_version always ride.",
      +  "type": "boolean"
      +}
    • addedInput schema / properties / cursor
      Added value: +{
      +  "description": "Optional: the page.next_cursor from the previous page (the last symbol returned). Omit for the first page.",
      +  "type": "string"
      +}
    • addedInput schema / properties / fields
      Added value: +{
      +  "description": "Optional: keep only these engine_fields keys per name (e.g. [\"stop\",\"target\",\"rr\"]). Unknown keys are echoed in unknown_fields. With compact=true this replaces the core engine-field set.",
      +  "items": {
      +    "type": "string"
      +  },
      +  "type": "array"
      +}
    • addedInput schema / properties / limit
      Added value: +{
      +  "description": "Optional: page size, names per page (sorted by symbol). The response carries page.next_cursor.",
      +  "maximum": 1000,
      +  "minimum": 1,
      +  "type": "integer"
      +}
  2. Added

TDQS

A4.2/5.0
Behavior3/5

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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive) and openWorldHint, so the description is not carrying that burden. It does add real context beyond them: ~5-minute refresh in market hours, identical output for every subscriber, a subscription/connector prerequisite, the dip-candidate gate semantics, and the self-describing `schema` block that is omitted under compact=true. The one weak spot is that this behavioral detail is buried in a dense paragraph rather than surfaced plainly.

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?

Purpose is front-loaded and nearly every sentence carries operative information (sizing, compact semantics, dip gate, freshness, auth prerequisite), so there is little pure filler. It is still a dense block with nested parentheticals that reads more like a spec sheet than a scannable brief, which costs it a point.

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?

There is no output schema, yet the description explains the payload shape (names[] with engine_fields, candidates[], the `schema` metadata block), what compact=true drops versus what always rides (candidates, freshness, rules_version), and how quickly data refreshes. For a five-parameter, zero-required read with no output schema, that is close to fully complete.

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?

With 100% schema description coverage, the baseline is 3; this description goes further by quantifying the payload cost of each parameter combination (unfiltered vs 2-name symbols read vs compact, ~70 KB vs ~12 KB) and by clarifying that limit/cursor page by symbol while fields[] selects engine keys that compact=true would otherwise replace. That is meaning the schema does not supply.

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?

It names the concrete resource (the Coil Live engine feed) and enumerates what each name carries: structural stop/target with basis, risk-reward, buy score, conviction, entry lane, plus actionable candidates. It also positions itself against a sibling by calling itself 'a superset of the complete live board' that additionally carries the leveraged vehicle and ladder placement, so an agent can tell it apart from get_full_board.

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 sizing walkthrough is genuinely actionable routing guidance: it tells the agent to use symbols[] for a targeted read (~70 KB) and compact=true for broad sweeps (~350 KB) versus the 1.35 MB unfiltered pull. It also flags that it returns live data only for signed-in subscribers. What it lacks is an explicit when-not rule pointing at get_full_board or get_buy_list for simpler needs.

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.

Resources