Skip to main content
Glama

list_directional_bots

Directional building-block bots: always long / always short BTC, ETH, SOL. Pure exposure, no edge — use them to express a market view in a formation (e.g. news is bullish for BTC -> a formation heavy in dir_long_btc). Allowed in personal and standard funds.

Input Schema

NameRequiredDescriptionDefault

No arguments

Output Schema

NameRequiredDescriptionDefault
resultYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A3.6/5.0
Behavior3/5

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

No annotations are present, so the description carries the burden. It discloses useful traits — 'Pure exposure, no edge' and 'Allowed in personal and standard funds' — but these describe the bots rather than the tool's behavior (e.g., no pagination, no filtering, no result-size note). For a zero-parameter list tool with an output schema, this is adequate but not rich.

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-loaded with the resource definition, then the use case and constraints. Dense but every clause (what it is, how to use it, where it's allowed) earns its place; only the trailing constraint sentence is arguably secondary.

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 simple zero-arg list tool with an output schema, the description supplies the category definition, a motivating use case, and eligibility constraints. It stops short of stating how results relate to broader bot listings, but that is a minor gap given the output schema and simplicity.

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 schema defines zero parameters, which is the baseline-4 case. No parameter semantics are needed, and the description does not waste words on nonexistent inputs.

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 description clearly identifies the resource as a specific category: 'Directional building-block bots: always long / always short BTC, ETH, SOL.' This distinguishes it from generic siblings like list_bots, though it never explicitly uses a listing verb (implied by the name) and doesn't state whether this is a subset filter of all bots.

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?

It gives a usage context ('use them to express a market view in a formation') with a concrete example, which implies when to reach for it. However, it does not compare against alternatives like list_bots, list_my_bots, or get_marketplace_bots, so the agent must infer that this is the directional subset.

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.