Skip to main content
Glama
Charlie85270

derive-options-mcp

by Charlie85270

Coins with option chains

list_currencies
Read-only

Identify tradeable coins, view their current prices, and see the number of listed expiries to evaluate option opportunities.

Instructions

Which coins can be traded here, with their current price and how many expiries are listed.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
currenciesYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A4.1/5.0
Behavior4/5

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

Annotations already declare readOnlyHint=true, so no safety concern is hidden. The description adds useful behavioral context by revealing the output scope: current price and expiry counts, which helps the agent know what to expect beyond the title alone.

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 a single, front-loaded sentence that conveys the core purpose and the key output fields with no wasted words. Every part adds value.

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 zero-parameter, read-only listing tool with an output schema, the description is sufficiently complete. It explains what the list contains and the count of expiries, leaving little ambiguity for an agent selecting or invoking the tool.

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 nothing for the description to document in terms of inputs. The baseline of 4 applies, and the description appropriately focuses on the returned data rather than parameter usage.

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 states that the tool lists tradable coins, their current price, and the number of listed expiries, which goes beyond the generic title. It distinguishes the resource (currencies/coins) from siblings like list_expiries or get_spot, though it does not explicitly name alternatives.

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

Usage Guidelines4/5

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

The phrase 'Which coins can be traded here' gives clear context for when to use this tool: when an agent needs to discover available coins and their option-chain activity. It does not explicitly mention exclusions or alternative tools, but the intended use case is evident.

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