Skip to main content
Glama
tinoxbt

preflight-mcp

by tinoxbt

Show the active rules

preflight_rules

Inspect the thresholds and environment variables that define trading order preflight checks, clarifying why orders receive CLEARED, REFUSED, or UNREADABLE verdicts.

Instructions

The thresholds every decision is measured against, and the environment variable that changes each one. A guard whose rules cannot be read is a guard nobody can argue with, and an operator who cannot see the ceiling cannot tell a refusal from a bug.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.0.0

TDQS

B3.2/5.0
Behavior3/5

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

With no annotations, the description carries the behavioral disclosure burden. It reveals that an environment variable can change each threshold and that this tool exposes those thresholds, which is useful. However, it does not explicitly state whether the operation is read-only, what the output contains, or how the environment variable affects the response.

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

Conciseness3/5

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

The first sentence is informative and front-loaded. The second sentence is rhetorical and metaphorical, adding emphasis but no concrete operational detail; it does not fully 'earn its place' in an AI-facing description.

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?

The tool is simple with no parameters, but there is no output schema and no annotations. The description states that thresholds and their environment-variable dependencies are shown, yet it omits the actual environment variable name and the return shape, leaving minor but real gaps for an agent.

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?

The tool has zero parameters, so there is no schema burden to compensate for. The mention of an environment variable that changes thresholds is the only semantic detail relevant to invocation, and it is adequate for a parameterless tool.

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?

The title 'Show the active rules' provides a clear verb and resource, and the description adds that these are the 'thresholds every decision is measured against.' It is distinguishable from siblings like preflight_trade by focusing on rules/thresholds rather than execution, though it does not explicitly name an alternative.

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

Usage Guidelines2/5

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

The description implies the rules matter for decisions ('every decision is measured against'), but it gives no explicit guidance on when to call this tool versus preflight_trade or market_snapshot. There are no stated exclusions, prerequisites, or recommended call contexts.

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

Install Server

Other Tools