Skip to main content
Glama
Sign In
coinopai-mcp

coinopai-mcp

by forgemeshlabs
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Remote

audit_trade_decision

Audit a Kronos decision against actual market prices. Get direction accuracy, PnL%, and a verdict: GOOD_DECISION, BAD_DIRECTION, NOISE, or NO_ACTION_TAKEN.

Instructions

The accountability step. Verify a Kronos decision_id against later market prices. Returns whether direction held, PnL%, and a verdict: GOOD_DECISION, BAD_DIRECTION, NOISE, or NO_ACTION_TAKEN. Costs $0.07 USDC.

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": {
      "decision_id": "<decision_id>"
    },
    "name": "audit_trade_decision"
  }
}

Input Schema

NameRequiredDescriptionDefault
windowNoEvaluation window: 1h, 4h, or 24h (default: 4h)
decision_idYesUUID from a previous get_crypto_decision call
affiliate_idNoOptional Pyrimid affiliate ID (af_xxxxx). Affiliate earns a commission from within the listed price — no extra cost to you.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.2.6

TDQS

A4.2/5.0
Behavior4/5

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

With no annotations provided, the description carries the full burden. It discloses the monetary cost ($0.07 USDC) and the return format (direction, PnL%, verdicts). However, it does not specify whether the operation is read-only, what happens if the decision_id is invalid, or any authentication requirements.

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

Conciseness5/5

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

The description is extremely concise—two sentences and a brief verdict list. Every word adds value: purpose, cost, return types. No redundancy or fluff.

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?

Given no output schema, the description adequately covers return values (direction, PnL%, verdicts). It also mentions cost as a contextual factor. However, it lacks details on error handling or what happens when the decision_id doesn't exist, which would be helpful for completeness.

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%, but the description adds valuable context: decision_id is a 'UUID from a previous get_crypto_decision call', window has a default and options, affiliate_id is optional with cost clarification. This enhances understanding beyond the parameter descriptions.

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 clearly states the tool's purpose: 'Verify a Kronos decision_id against later market prices.' It uses a specific verb ('verify') and resource ('decision_id') and distinguishes from siblings like get_crypto_decision by focusing on post-hoc verification.

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 phrase 'The accountability step' implies usage after a decision is made, but no explicit when-to-use or when-not-to-use guidance is provided. Alternatives (e.g., get_crypto_decision) are not mentioned, and there are no exclusions or prerequisites.

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