What can you do with this server?

This server is a read-only MCP cost gate for Gryps v2 trading: it checks whether a trading signal can survive real execution costs, fees, spread, funding, and liquidation risk before an agent acts. * Measure the round-trip friction floor a trade must beat, decomposed into fees and spread with provenance. * Cost-gate any claimed edge from external signals, flagging when a verdict depends on unresolved fee-basis ambiguity. * Combine agreeing signals honestly, avoiding double-counting correlated or same-source confirmations. * Analyze liquidation risk via margin profile, position-size limits, and survivability against expected price moves. * Estimate holding costs such as funding over time, not just entry/exit fees. * Compare Gryps round-trip cost against a public order-book venue using live depth. * Get indicative, non-firm execution estimates derived from oracle price plus measured friction. * Compare Gryps oracle price to an external fair-value mid and report divergence in bps. * Browse and resolve live Gryps v2 markets, with filtering by category or RFQ availability. * Read venue funding parameters, aggregated open interest, chain-side liveness/heartbeat, and a verified operational quirks registry. * View measured real-world fees from settlement event logs and the engine-reported fee schedule. * Run paper-session rehearsals against live prices, decomposing results into price move versus friction. * Check venue status, capabilities, limitations, and next-step guidance; browse staged prompt journeys. * Perform all operations read-only and non-destructive: it cannot trade, sign, withdraw, or access private accounts.

How do I use @gryps/agent-mcp?

1. Click on "Deploy Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@@gryps/agent-mcp what's the current funding rate for BTC?" That's it! The server will respond to your query, and you can continue using it as needed. Here is a step-by-step guide with screenshots.

@gryps/agent-mcp

Official

by gryps-finance

Overview Schema Source Related Servers Discussions Admin

TypeScript

Remote

Gryps Agent MCP

Checks whether a trading signal can survive execution reality before an agent acts.

The AI tool shelf is saturated with reasons to trade: sentiment feeds, news feeds, technical indicators, on-chain analytics, research summaries. It is starved of anything that asks whether a claimed edge can pay for its own execution. This server is that gate.

It reads live Gryps v2 market and venue data through the Model Context Protocol, measures what a round trip actually costs, and tells an agent when a trade is not worth making. It cannot place trades, sign messages, manage session keys, read private accounts, or expose internal Gryps systems, and it is built so that a routine upgrade can never quietly change that.

Quick start

Requires Node.js 22.13 or later. See CONNECT.md for the full two-minute setup, including client configuration and troubleshooting.

npx -y gryps-agent-mcp@alpha

To run the unreleased main branch instead: npx -y github:gryps-finance/gryps-agent-mcp.

Example MCP client configuration:

{
  "mcpServers": {
    "gryps": {
      "command": "npx",
      "args": ["-y", "gryps-agent-mcp@alpha"]
    }
  }
}

Then ask your client:

A sentiment feed says BTC is about to move 15 basis points. Use Gryps to check whether that clears the cost of trading it.

Related MCP server: Blocksize Market Data

What it does

Tool	Purpose
`gryps_friction_floor`	The round-trip cost a trade must beat, decomposed into fees and spread with full provenance. The number that decides whether a trade is worth making.
`gryps_edge_check`	Cost-gate a claimed edge from any upstream signal source. Answers whether the claimed magnitude survives execution, never whether the signal is true.
`gryps_signal_stack`	Combine several agreeing signals honestly. Folds repeats of one source into a single signal, treats near-identical source names as one feed, and prevents correlated families from being counted as independent confirmations.
`gryps_margin_profile`	Where the position gets liquidated. Turns the venue published maintenance-margin ladder into the bracket, margin, leverage ceiling, and adverse move a size can absorb — and whether it survives long enough for the expected move to arrive.
`gryps_position_size`	How large. Bounded by the cost gate, the risk budget, the venue brackets, and survivability, reporting the largest size every constraint allows and naming the one that binds.
`gryps_funding_cost`	What holding costs, beside what entering costs. Over a long hold, carry can exceed the round trip entirely.
`gryps_route_compare`	Compare round-trip cost on Gryps against a public order-book venue priced by walking its live displayed depth.
`gryps_indicative_quote`	An indicative, non-firm execution estimate for one clip: oracle mid, estimated entry, and the all-in cost model. Derived, and labeled as such: the engine exposes no quote surface.
`gryps_reference_price`	The live Gryps oracle price next to an external fair-value mid, with divergence in bps. The anchor for oracle sanity checks and paper-session pricing.
`gryps_list_markets`	Browse the live v2 market catalogue with bounded search and pagination. Searches by common name (`bitcoin`, `matic`), and when nothing matches, names the nearest listed symbols as explicit guesses.
`gryps_get_market`	Resolve one exact symbol, common name, or unique base asset and return live price and leverage limits. Reports which route resolved it.
`gryps_measured_fees`	The median fee real fills actually paid, read from the settlement contract event log. A fill is a fact; a schedule is a claim.
`gryps_get_fee_schedule`	The engine-reported fee tier ladder.
`gryps_capabilities`	One call describing what the server answers, what it refuses, what it reads, and every known limitation with its consequence.
`gryps_next_step`	Ask what to do next. On a fresh install it returns one starting point rather than a catalogue, then routes the journey from there.
`gryps_prompt_library`	Browse 25 staged prompts by journey stage, experience level, purpose or free text. Each says what it does and why it matters.
`gryps_paper_session`	Rehearse trades against live prices with zero capital. Every close decomposes the result into price move versus friction paid. No order exists anywhere.
`gryps_venue_status`	API health, build version, and settlement identity checked against the chain and contract pinned in this package rather than relayed from the endpoint.

All tools are annotated read-only and non-destructive. Every response uses a versioned JSON envelope naming its live source, fetch time, and limitations.

What an agent is told on connect

The server sends MCP instructions on initialize, so any client passes them to the model as standing context without the user doing anything. They frame the server as a cost gate rather than an idea source, point a new install at gryps_next_step, and name the four ways an agent could mislead someone with these tools.

The seven journey prompts are also exposed as native MCP prompts, so clients that render prompts surface the guided path in their own interface. A tool has to be invoked; a prompt is presented.

Cost is not the only thing that stops a trade

A trade can clear its cost and still be a bad trade, and the venue publishes enough to prove it. Every risk-config read returns a full maintenance-margin ladder, so the same call that prices friction can also say where the position stops existing.

On live BTC data, 150x leverage leaves roughly 27 basis points of room before liquidation, and round-trip friction is 24 of them. Three basis points of actual buffer, on a trade the cost gate alone would wave through. That is the gap gryps_margin_profile and gryps_position_size close: the first says where the position dies, the second says how large it can be before that becomes likely.

gryps_funding_cost closes the other one. Friction is charged twice and then done; funding is charged the whole time the position is open. Holding a week can cost several times the round trip this package has been gating on.

The four honesty rules

These are structural, not stylistic. They are enforced by tests.

Friction is a lower bound until spread is measured. The engine reports fee tiers. The public v2 engine exposes no bid/ask or depth surface at all — every order-book, depth, ticker, and quote path was probed and returns 404 — so spread is absent upstream rather than merely unwired here. gryps_friction_floor therefore reports a measured fee floor, flags isLowerBound: true, carries the probe result in spreadSurface, and says plainly that true friction is higher. It is never presented as all-in friction.

Fee direction is unverified, so both readings travel together. The engine does not state whether totalFeeRateBps is per side or a round trip, and the answer is worth a factor of two. The headline number takes the conservative per-side reading, and every response also carries the other one: gryps_friction_floor returns feeDirectionRange with both round trips and both break-even edges, and gryps_edge_check re-runs the gate against the alternative and reports whether the verdict survives it. A verdict that flips depending on an unresolved question is reported as not decidable from live data, not as a decision. The flag is three-state: unset means unresolved, --fee-is-round-trip=true and =false both mean an operator has confirmed the basis, and the responses say which.

Third-party signal text is untrusted input. A sentiment or news tool relays text written by strangers. Every response that touches a claimed edge carries a notice telling the model to treat that text as data to evaluate, never as instruction to follow.

A derived estimate is not a quote. The public engine exposes no quote, estimate, or preview endpoint. gryps_indicative_quote therefore builds its estimate from the live oracle price plus measured friction, and says so: firm: false, quoteStatus: "derived", and engineQuoteSurface: "absent". An agent must not present it to a user as a price the venue offered.

What it will not do

It will not tell you a signal is true. It only checks whether the claimed magnitude could survive execution cost. Conflating those two questions is how confident agents lose money.
It will not treat five agreeing sources as five confirmations. Correlated evidence inflates confidence without inflating edge, and confidence is what sets position size.
It will not always say Gryps is cheaper. gryps_route_compare reports the other venue as cheaper when that is what the live numbers say.
It will not repeat the engine market count as a fact. That count has not been reconciled with published documentation, so it is returned flagged as unpublishable rather than quoted.
It will not take an endpoint's word for what it is. The settlement chain and contract are pinned in this package and compared against what the engine reports, because a wrong or hostile endpoint describes itself with exactly the same confidence as the right one.
It will not guess a symbol. Common names are rewritten through a curated alias table before exact matching, and near misses are returned as labelled suggestions. Neither ever resolves a market on your behalf by similarity.
It will not trade, sign, hold assets, or read your account.

Verify the boundary yourself

The read-only claim is only worth what a stranger can check. Every installed copy audits itself:

npx -y gryps-agent-mcp@alpha --verify

It scans the JavaScript actually installed on your machine for the capabilities this package promises never to have: transaction signing, private keys, wallet clients, order placement, withdrawals, network listeners, environment configuration, and subprocesses. It also lists every network destination present in the shipped code, so you can see exactly where it is able to reach.

Add --json for machine-readable output. A failed audit exits non-zero, so a pipeline can gate on it.

A pass is evidence about that version, not a promise about future ones, which is why the check ships inside every version rather than living only in this repository.

Configuration

Configuration is explicit and never read from environment variables.

npx -y gryps-agent-mcp@alpha \
  --api-base=https://example.invalid/api/v1 \
  --health-url=https://example.invalid/health \
  --comparison-url=off \
  --spread-bps-per-side=8

Flag	Effect
`--api-base=`, `--health-url=`	Override the Gryps read endpoints. HTTPS only, except loopback.
`--timeout-ms=`, `--cache-ttl-ms=`	Upstream request timeout and read cache TTL.
`--comparison-url=`	Order-book venue for `gryps_route_compare`. Use `off` to disable venue comparison entirely.
`--comparison-taker-fee-bps=`	Taker fee assumed for the comparison venue, per leg. An assumption, stated in every response.
`--fee-is-round-trip=`	Declare the fee basis once the protocol team confirms it. Unset means unresolved and both readings are reported; `true` roughly halves the reported floor; `false` confirms the per-side reading the server already assumes.
`--spread-bps-per-side=`	Supply an operator-measured spread. Doing so stops friction being reported as a lower bound.
`--help`, `--version`	Print usage or version and exit.

Query strings and fragments are stripped from configured endpoints. Upstream reads are cached briefly, deduplicated in flight, retried once on transient failures, and rejected above 5 MB.

Development

npm ci
npm run verify:release
npm run smoke:live

verify:release type-checks, tests, builds, exercises the MCP handshake, and inspects the npm tarball allowlist. smoke:live separately verifies the live endpoint, the friction floor, the cost gate, and venue comparison, because it requires network access. CI runs the same chain on Linux and Windows plus a nightly live-contract check for upstream drift.

See CONNECT.md to connect an agent in two minutes, ARCHITECTURE.md for the capability split, SECURITY.md for the defensive boundary and reporting path, RELEASE.md for the publication gate, CONTRIBUTING.md for the ground rules, and ROADMAP.md for the path from public read to supervised execution.

Gryps-owned account observer

This repository also contains a private observer profile that reads one wallet's account snapshot, portfolio, order history, and trades. It is excluded from the public npm tarball and requires the wallet address to be fixed when the process starts:

npm run verify:internal
npm run start:internal -- --account-address=0xYOUR_40_HEX_CHARACTER_ADDRESS

The observer cannot sign, submit, cancel, or withdraw. Its presence in the source repository does not change the public package boundary.

Available Tools

6 tools

gryps_get_fundingC

Funding parameters for a Gryps market (epoch duration, max rate).

ParametersJSON Schema

Name	Required	Description	Default
`symbol`	Yes

TDQS

C2.9/5.0

Behavior2/5

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

No annotations provided, so description bears full burden. It states what data is returned but does not disclose any behavioral traits such as read-only nature, potential side effects, authorization requirements, or rate limits.

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 11-word sentence that front-loads the key purpose and specific fields. No extraneous text.

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?

Given the tool's simplicity (1 parameter, no output schema, no annotations), the description is minimally adequate. It names the returned fields but lacks details on output format or parameter semantics. The absence of output schema means the agent cannot infer return structure beyond the brief field list.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema has 1 parameter (symbol) with 0% description coverage in schema. Description does not explain the parameter's meaning or usage, only implying it identifies the market. The description adds minimal value beyond the schema.

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?

Description clearly states the tool retrieves funding parameters for a Gryps market, mentioning specific fields (epoch duration, max rate). It distinguishes from siblings like gryps_get_market which likely returns market details. However, the description lacks an explicit verb but the tool name includes 'get'.

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?

No guidance on when to use this tool versus alternatives. The description does not mention when not to use it or provide context about which sibling tools cover different use cases.

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

gryps_get_marketA

Full detail for one Gryps market: leverage, notional bounds, live fee schedule, funding epoch, categories.

ParametersJSON Schema

Name	Required	Description	Default
`symbol`	Yes	e.g. BTC, XAU, SEIUSDT

TDQS

A3.8/5.0

Behavior3/5

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

No annotations provided. Description lists return fields but does not explicitly state read-only nature, permissions, or side effects. For a 'get' operation, it's adequate but not fully transparent.

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?

Single sentence that efficiently conveys purpose and key return fields. No wasted words, front-loaded with 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?

No output schema, but description lists return fields explicitly. Covers main aspects of a single-market detail tool. Could include more on response format or size, but sufficient for the agent to understand what to expect.

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?

100% schema coverage. Description provides examples for symbol parameter (BTC, XAU, SEIUSDT), same as schema description. Adds no new meaning beyond schema, baseline 3.

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?

Clear verb and resource: get full detail for one Gryps market. Lists specific fields (leverage, notional bounds, fee schedule, funding epoch, categories), distinguishing it from siblings like gryps_list_markets (list all) and gryps_get_funding (funding specific).

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?

Implies use when needing full market details, but no explicit when-to-use or when-not. No mention of alternatives like gryps_list_markets for overview or gryps_open_interest for interest data.

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

gryps_list_marketsA

List live Gryps markets. Supports filtering by category (e.g. "Commodities", "Stocks", "RWA") or RFQ availability. Fees and leverage are live venue data.

ParametersJSON Schema

Name	Required	Description
`limit`	No
`rfqOnly`	No	Only RFQ-enabled markets
`category`	No	Filter by category tag

TDQS

A3.9/5.0

Behavior3/5

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

No annotations are provided. The description mentions that fees and leverage are live venue data, but does not disclose other behavioral traits like rate limits, data freshness guarantees, or authentication requirements. The description is neutral but lacks detail.

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?

Two sentences: first states the core purpose, second adds filtering and data nature. No unnecessary words. Front-loaded and efficient.

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?

Adequate for a list tool with no output schema. Missing details on pagination (how limit works, default), sorting, and response structure. With no annotations, more behavioral context would be helpful.

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 67% (rfqOnly and category have descriptions, limit does not). The description adds value by giving examples for category ('Commodities', 'Stocks', 'RWA') and indicating that fees/leverage are live data. This supplements the schema well.

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 it lists live Gryps markets, with filtering options. It distinguishes from siblings like gryps_get_market (single market) and gryps_venue_liveness (venue status), so purpose is specific and differentiated.

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 description implies usage for listing markets with filters, but does not explicitly state when to use this tool versus alternatives like gryps_get_market or gryps_venue_liveness. No exclusion criteria or when-not-to-use guidance is provided.

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

gryps_open_interestA

Aggregated open interest snapshot for the venue (raw upstream shape, timestamped).

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A3.7/5.0

Behavior2/5

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

No annotations are provided, so the description must fully disclose behavior. It mentions 'raw upstream shape' and 'timestamped' but does not clarify if the operation is read-only, requires authentication, or has side effects. More detail on the nature of the query (e.g., is it cached? real-time?) would improve transparency.

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, efficient sentence that conveys the tool's purpose and key characteristics. It is front-loaded with the most important information and contains no filler.

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?

Given the lack of output schema and low complexity (0 parameters), the description is fairly complete but lacks detail on the exact return format. 'Raw upstream shape' is vague; stating the structure or fields would improve 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?

There are zero parameters and the empty schema is fully covered. The description adds value by describing the output as 'aggregated', 'raw upstream shape', and 'timestamped', which provides context beyond the schema. Baseline is 4 for no parameters, and the description justifies it.

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 it provides an 'aggregated open interest snapshot' for the venue, specifying 'raw upstream shape' and 'timestamped'. This distinctively separates it from sibling tools like gryps_get_funding (funding rates) and gryps_get_market (market data).

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?

While the tool's name and description imply it's for open interest data, there is no explicit guidance on when to use it versus alternatives, nor any prerequisites or exclusions. The sibling names provide some context but the description itself lacks usage directives.

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

gryps_venue_livenessA

Chain-side venue heartbeat for Gryps v2 (PerpsRollup on Polygon): state root, sequence number, USDC custody, current implementation. Works even when the venue API is down — the chain is the truth source.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A4.7/5.0

Behavior5/5

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

No annotations provided, so description carries full burden. It reveals key behavioral details: returns specific data (state root, sequence number, custody, implementation), functions as a chain-side source of truth, and works independently of API status. No contradictions.

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?

Two sentences, no wasted words. First sentence lists key data points and context; second sentence adds crucial usage advantage. Efficiently front-loaded.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The description fully covers what the tool returns and when to use it. With no output schema, the description serves as the sole documentation for return values, which it provides clearly. Adequate for a simple, stateless read 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?

Tool has zero parameters, so schema coverage is 100%. The description does not need to add parameter info. Baseline for zero params is 4, and no additional context is required.

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: a chain-side venue heartbeat providing state root, sequence number, USDC custody, and current implementation. It differentiates from sibling tools which focus on funding, markets, open interest, and quirks.

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 description explicitly highlights when to use this tool: even when the venue API is down, as the chain is the truth source. It implies reliability checks over API-dependent data, though it doesn't explicitly list exclusions or alternative tools.

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

gryps_venue_quirksC

Venue Quirks Registry: dated, verified operational quirks with machine-actionable agent rules (fee conventions, funding grids, accounting identities, API churn). Filter by venue and/or severity.

ParametersJSON Schema

Name	Required	Description	Default
`venueId`	No	e.g. gryps-orbs-v1, gryps-v2-polygon
`severity`	No

TDQS

C2.9/5.0

Behavior2/5

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

No annotations are supplied, and the description does not disclose behavioral traits such as side effects, idempotency, or authentication requirements. It implies a read operation but never explicitly confirms this, which is a gap given the lack of annotations.

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 a single, well-structured sentence that conveys the purpose and key details without unnecessary verbosity. It front-loads the core concept and uses examples efficiently.

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?

For a simple tool with two optional parameters and no output schema, the description covers the basic purpose and filtering capabilities. However, it does not describe the response format or any pagination/ordering, leaving some gaps in completeness.

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 50%, with venueId having an example in the schema and severity being an enum. The description adds the concept of filtering but does not elaborate on parameter format or constraints beyond what the schema provides. Per the rubric, a baseline of 3 is appropriate given the moderate coverage.

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 it is a registry of dated, verified operational quirks with machine-actionable agent rules, and mentions filtering by venue and severity. This distinguishes it from sibling tools like venue_liveness or funding. However, it does not explicitly state the action (e.g., 'query' or 'retrieve'), slightly reducing clarity.

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?

No guidance is provided on when to use this tool versus alternatives such as gryps_venue_liveness or gryps_get_funding. The description only states filtering options, leaving the agent to infer appropriate contexts.

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

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

6 tool updatesv0.2.0Jul 10, 2026
- First observedgryps_get_funding
- First observedgryps_get_market
- First observedgryps_list_markets
- First observedgryps_open_interest
- First observedgryps_venue_liveness
- First observedgryps_venue_quirks

Deploy Server

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A3.7/5.0

Scored 2026-07-10 21:40 across 6 tools

Disambiguation5/5

Each tool targets a distinct aspect of the Gryps venue: funding parameters, market details, market listing, open interest, liveness, and quirks. There is no overlap between them, making tool selection unambiguous.

Naming Consistency4/5

All tool names use snake_case and prefix 'gryps_'. Most follow a verb_noun pattern (e.g., gryps_get_funding, gryps_list_markets), but gryps_open_interest lacks an explicit action verb, creating a minor inconsistency.

Tool Count5/5

With six tools, the set is well-scoped for an MCP server focused on venue data. Each tool serves a clear purpose without redundancy, and the count is neither too small nor too large.

Completeness4/5

The tools cover key read operations for a venue (listing, details, funding, open interest, liveness, quirks). While missing potentially useful endpoints (e.g., historical data or trades), the set feels complete for its informational focus.

Maintenance

ActivityMaintained

ResponsivenessNo issues

Resources

Need Help?

Related Servers

Related MCP Connectors

The Quiet Protocol Growth Offense MCP A
com.thequietprotocol.www
Read-only MCP server for The Quiet Protocol's engines, benchmarks, proof, and business data.
Databases Research & Data Finance
292
FarmNeural Public API
com.farmneural
Public, read-only MCP server for FarmNeural company facts, packages, and capabilities.
Documentation Access Developer Tools
1
AIStatusDashboard
io.github.aistatusdashboard
Read-only MCP server for AIStatusDashboard status, incidents, metrics, and fallback recommendations.
Monitoring Observability
2
Hyperliquid Market Data — OHLCV, Funding Rates & Positioning (Tessera Analytics)A
dev.tesseralytics
Hosted Hyperliquid MCP server: query OHLCV, funding and positioning data in plain language with a free API key.
Blockchain Cryptocurrency Finance
52

Related MCP Servers

mcp-pear
Finance Cryptocurrency Blockchain
MarvelNwachukwu
A
license
A
quality
B
maintenance
Read-only MCP server for Pear Protocol that gives Claude access to markets, pair ratios, positions, orders, trade history, and portfolio.
Updated 2 months ago (2026-07-18 22:02 UTC)
20
82
1
MIT
Blocksize Market Data
Cryptocurrency Finance Web3 & Decentralized Tech
jf-cmyk
A
license
A
quality
D
maintenance
Read-only MCP server for Blocksize market data discovery, pricing, documentation, and x402 endpoint lookup across crypto, equities, FX, and metals.
Updated 3 months ago (2026-06-17 23:10 UTC)
7
1
MIT
hl-read
Cryptocurrency Blockchain Finance
akagifreeez
A
license
Not graded
quality
C
maintenance
A read-only MCP server for Hyperliquid that provides public market data (prices, order books, funding) and any wallet's positions, orders, and fills via MCP tools, without requiring a private key.
Updated 21 days ago (2026-08-23 04:51 UTC)
MIT
hyperliquid-mcp
kitsune-de
A
license
A
quality
B
maintenance
A read-only MCP server for querying Hyperliquid perp markets, funding rates, order books, candles, and account positions/fills/funding for any address, without needing API keys or wallets.
Updated 2 months ago (2026-07-18 02:00 UTC)
8
55
1
MIT