Skip to main content
Glama

mcp

by com.bitcoincreditstack

One venue against the published criteria

get_venue

What is known about this venue, criterion by criterion? The three pillars — Price, Quality, Composition — each cell with its value and the source it came from.

The criteria are published and versioned before any venue is measured against them, applied evenly to every row, and the spec version rides in this payload. There is no composite score, no stars and no reliability index: a reader weighs the criteria, and this server does not weigh them for the reader.

⚠ 'unknown' is a value, not an omission — a criterion that cannot be established from public sources says so with its reason. A class-specific 'not_applicable' and an unresearched 'unknown' are different answers and are never conflated.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
venue_idYesRegistry id, e.g. 'aave_v3_arbitrum'. Call list_venues to discover valid ids.

TDQS

A3.9/5.0
Behavior4/5

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

With no annotations, the description carries the behavioral burden and does so well: it clarifies there is no composite score/stars/reliability index, that 'unknown' is a meaningful value, and that 'not_applicable' versus 'unknown' are distinct. It also notes the criteria are versioned and the spec version is in the payload, which is useful behavioral context beyond a simple read operation.

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?

The description is moderately sized and front-loads the primary output, then adds necessary interpretive caveats. Some phrasing is slightly elaborate, but each section earns its place and the key information is not buried.

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?

The description is complete enough for a single-parameter read tool with no output schema: it explains what is returned, how values are sourced, that no composite score is provided, and how special values behave. Minor omissions like response format are not critical given the simplicity of the tool.

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 description coverage is 100% and the schema already explains venue_id with an example and a pointer to list_venues. The description adds no additional parameter-level semantics, so the baseline of 3 applies.

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 identifies the tool as returning a criterion-by-criterion assessment of a single venue across the three pillars (Price, Quality, Composition), including values and sources. The title 'One venue against the published criteria' and the contrast with the sibling compare_venues helps distinguish it from other venue-related tools.

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 tool's purpose implies use for a single venue rather than comparison, but it does not explicitly state when to use this tool versus alternatives such as compare_venues or list_venues. Usage context is present but not made explicit through when-to-use or when-not-to-use guidance.

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

All mcp toolsInspect
Try in Browser
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A4.3/5.0
Disambiguation4/5

Most tools have clearly distinct scopes: compare_venues is per-venue pricing, get_credit_state is a cross-venue aggregate, and get_market_composition/get_market_flows are explicitly Morpho Blue-only. The main ambiguity is between list_indicators and list_onchain_indicators, which overlap significantly since the former already includes an onchain family.

Naming Consistency5/5

Tool names consistently follow a lowercase snake_case verb_noun pattern: get_credit_state, get_venue, list_indicators, list_venues. compare_venues is the only non-get/list verb but still fits the verb_noun convention, so the set reads predictably.

Tool Count5/5

Thirteen tools is well within the ideal 3-15 range for a read-only market-data server. Each tool covers a distinct retrieval need: aggregates, histories, venue details, indicators, verification, market composition, flows, and presentation lenses.

Completeness4/5

The server covers discovery and lookup well: list_indicators/get_indicator, list_venues/get_venue, aggregate credit state with history, market composition/flows, MVRV, verification bundles, and lenses. Minor gaps exist: list_onchain_indicators implies multiple onchain indicator tools but only get_mvrv is actually exposed, and there is no historical series for market composition or flows.

Resources