Skip to main content
Glama
Sign In
pathiel

pathiel

by Julian-dev28
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

submit_desk_call

Record your own trade call in a desk's local journal with side, instrument, confidence, and invalidation so it can be graded later against machine theses; places no order.

Instructions

Record the user's own trade call on a desk in the local journal (author=user), graded later beside the machine's theses in get_desk_record. call needs side (long, short, flat or pair), instrument, a one-liner of at most 160 characters, confidence from 0 to 1 and the invalidation; entry_px (or an entry_zone [lo, hi]), stop_px, targets and leverage are optional. scenarios, when given, are {name, probability, move_lo_pct, move_hi_pct (percent moves), description, triggers[]} whose probabilities sum to 1; a call that breaks a rule returns {error} naming it. Places no order and changes no config. Use when the user states a view they want tracked; to trade it use place_bracket. Returns the journaled call.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "desk": "<desk>",
      "call": "<call>"
    },
    "name": "submit_desk_call"
  }
}

Input Schema

NameRequiredDescriptionDefault
callYesThe trade in one shot.
deskYesDesk id from list_desks (oil, metals, ...).
notesNoFree-text notes kept with the call.
scenariosNoOptional probability-weighted outcome scenarios, must sum to 1

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv0.6.1

TDQS

A4.7/5.0
Behavior5/5

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

Annotations only supply destructiveHint=false, and the description adds substantial context beyond that: the write target is a local journal, the record is attributed to author=user, it is graded later in get_desk_record, rule violations return an {error} naming the rule, and scenario probabilities must sum to 1. The side-effect boundary (no orders, no config changes) is stated plainly, which matters for a mutation tool.

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?

It is front-loaded with the core action and closes with the when-to-use/alternative guidance, which is where it belongs. The middle sentences are dense run-ons packing required fields, optional fields, and the scenario shape together, which costs a bit of scannability.

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 tool with nested objects, required sub-fields, and no output schema, the description covers the required call fields, the optional ones, the scenario contract, and the return ('Returns the journaled call'). Only the free-text notes field and the validation surface beyond the probability rule go unmentioned, which is minor.

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?

Schema description coverage is 100%, so the baseline is 3; the description earns more by documenting behavior the schema does not: entry_px vs entry_zone [lo, hi] as alternatives, scenario moves being percent moves, and the probability-sum constraint. It restates a couple of schema facts (160-char one-liner, confidence 0-1) but adds real semantics on the nested objects.

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?

Opens with a specific verb and resource: 'Record the user's own trade call on a desk in the local journal (author=user)'. It also distinguishes itself from both get_desk_record (where it is graded later) and place_bracket (execution), so an agent can separate the three without opening any schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly states the trigger condition ('Use when the user states a view they want tracked') and names the alternative tool and its condition ('to trade it use place_bracket'). It also implicitly excludes execution by stating 'Places no order and changes no config', leaving nothing to infer.

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

Deploy Server

Other Tools