Skip to main content
Glama
Sign In

Insight Pre-Trade Safety

by io.github.imokokok
OverviewDiscussionsAdmin

position_lifecycle_step

Run one step inside a purchased Position Lifecycle bundle: guard (family-specific safety assessment), receipt (signed execution receipt), or close (combined summary). Guard and receipt cost zero extra credits inside the bundle. Returns the step result (guard verdict, signed receipt, or the combined lifecycle summary). Use it only with a lifecycle token from position_lifecycle_begin. Do not use it for unrelated positions and never reuse a token after close. Deprecated alias: prefer position_lifecycle with op "guard". Removed on 2027-01-06.

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": {
      "op": "<op>",
      "lifecycle_id": "<lifecycle_id>",
      "lifecycle_token": "<lifecycle_token>"
    },
    "name": "position_lifecycle_step"
  }
}

Input Schema

NameRequiredDescriptionDefault
opYes
familyNo
paramsNoNative family guard input (old shape)
receiptNoBundled execution receipt (old shape)
transactionNo
lifecycle_idYes
lifecycle_tokenYesOne-time plc_ token from the purchase

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • changedInput schema / properties / family / enum
      Previous value: -[
-  "base_perp",
-  "hyperliquid_perp",
-  "base_lending",
-  "monad_lending",
-  "multichain_evm_lending",
-  "solana_lending"
-]New value: +[
+  "base_perp",
+  "bnb_perp",
+  "hyperliquid_perp",
+  "solana_perp",
+  "base_lending",
+  "monad_lending",
+  "multichain_evm_lending",
+  "solana_lending"
+]
  2. Added

TDQS

A4.3/5.0
Behavior4/5

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

With no annotations supplied, the description carries the full burden and does well: it discloses credit cost (guard and receipt are free inside the bundle), the one-time nature of the token, the deprecation/removal date, and what each step returns. It stops short of describing failure behavior (expired/invalid token, out-of-order steps) or whether close invalidates the bundle beyond the token-reuse warning.

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?

Front-loads the operation enumeration, then moves through cost, returns, constraints, and deprecation in a logical order with no filler. It is dense with several distinct concerns packed into one paragraph, which slightly reduces scannability but not substance.

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?

No output schema exists, so the description steps in by naming what each op returns (guard verdict, signed receipt, combined summary), and it flags the deprecation and preferred replacement. Given 7 parameters with nested objects, the unexplained family/params/receipt shapes are the main remaining gap.

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 only 43%, and the description compensates for two parameters well: op values are explained and lifecycle_token's origin is stated. However family, params, receipt, and transaction (including the vague "old shape" hint) get no explanation in the description, leaving half the parameters undocumented in both places.

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?

States a specific verb and resource ("Run one step inside a purchased Position Lifecycle bundle") and enumerates the three operations with their meanings: guard, receipt, close. It also distinguishes itself from siblings by naming the deprecated status relative to position_lifecycle and by tying it to position_lifecycle_begin.

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?

Gives explicit preconditions ("Use it only with a lifecycle token from position_lifecycle_begin"), explicit exclusions ("Do not use it for unrelated positions"), a hard constraint ("never reuse a token after close"), and an alternative ("prefer position_lifecycle with op 'guard'"). This is close to a complete routing decision.

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

All Insight Pre-Trade Safety 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