A
licenseA
qualityD
maintenanceRead-only MCP server for Blocksize market data discovery, pricing, documentation, and x402 endpoint lookup across crypto, equities, FX, and metals.
7
1
MIT
gambit-mcp
Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type
@followed by the MCP server name and your instructions, e.g., "@gambit-mcpcheck schema compatibility for the quant research contract"
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.
gambit-mcp
Pre-production MCP server for bounded, read-only Gambit quantitative-research
workflows. The target protocol revision is 2026-07-28; MCP Python SDK 2.2.0
also serves the tested 2025-11-25 legacy era.
make setup
make check
uv run gambit-mcpM1 is complete and M2 market-data contract groundwork is underway:
gambit://server/aboutandgambit://capabilitiesresources;gambit_check_contract, a synthetic schema/compatibility tool;no market data, Gambit calculations, persistence, remote authorization, live trading, arbitrary code, filesystem paths, or arbitrary network access.
No market-data tool is exposed yet. The immutable Gambit artifact, ingestion
format, parser-isolation evidence, and data/quant semantic approvals remain M2
gates; see docs/M2_READINESS.md.
Set APP_TRANSPORT=streamable-http to run the pre-production HTTP transport on
localhost. It is not approved for remote production use.
Configuration uses APP_ environment variables documented in .env.example.
Production refuses to start with an untraceable revision. The inherited HTTP
health and container deployment contract must be adapted and requalified for the
MCP ASGI app before container promotion. See PROJECT_BRIEF.md,
docs/PROJECT_PLAN.md, and docs/MCP_SERVER_ENGINEERING_STANDARD.md.
Available Tools
1 toolgambit_check_contractCheck Gambit MCP contractA
Check compatibility with the walking-skeleton contract.
Use this before relying on this pre-production server. It validates only the MCP adapter contract. It does not validate data, run Gambit, backtest, calculate risk, or provide investment advice.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| contract_version | Yes |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| scope | No | |
| accepted | No | |
| server_version | No | |
| contract_version | No | |
| target_spec_revision | No |
TDQS
A4.7/5.0
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It clearly states the tool's limited scope ('validates only the MCP adapter contract') and enumerates what it does not do, providing honest expectations about its non-behavior and lack of side effects.
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 compact and well-structured: purpose first, then usage context, then explicit non-scope. Each sentence earns its place with no filler or repetition.
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?
Given the tool's simplicity, one fully-constrained parameter, an output schema, and no siblings, the description covers all necessary context: what it checks, when to use it, and what it does not do. Nothing important is missing.
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?
The description does not mention the contract_version parameter, and schema description coverage is 0%. However, the parameter is trivial: a single required string with const 'v1', fully specified by the schema. The description adds no semantic value, but none is genuinely needed here.
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?
States a specific verb ('Check') and resource ('compatibility with the walking-skeleton contract'), and clarifies that it validates only the MCP adapter contract. This is precise enough to distinguish it from any data/backtesting/risk tools, even though no siblings are listed.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly instructs when to use it: 'Use this before relying on this pre-production server.' It also lists exclusions—does not validate data, run Gambit, backtest, calculate risk, or provide investment advice—which prevents misuse despite having no sibling tools to compare against.
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.
1 tool update
v0.1.0- First observed
gambit_check_contract
TDQS
A4.5/5.0
Scored across 1 tool
Disambiguation5/5
With only one tool, there is no possibility of confusing it with another. The description clearly states exactly what it validates and what it does not, leaving no ambiguity.
Naming Consistency4/5
The name 'gambit_check_contract' follows a clear verb_noun pattern and is readable. However, with only one tool, there is no broader naming convention to assess, and the redundant 'gambit_' prefix is slightly awkward.
Tool Count3/5
A single tool feels thin for a server, even one with a narrow scope. It is usable for its stated purpose but provides agents with a very limited surface.
Completeness4/5
The server's stated purpose is limited to checking contract compatibility for a pre-production adapter, and the tool fully covers that purpose. Missing capabilities like data validation or backtesting are explicitly out of scope, so they are not true gaps, but the surface is still minimal.
Maintenance
ActivityMaintained
ResponsivenessNo issues
Related MCP Connectors
Read-only paper risk evidence and policy-gated committed event research. No real orders.
Read-only discovery and bounded access to a finite market briefing with evidence boundaries.
Read-only Autonomy capability, schema, status and pricing discovery. Paid execution remains paused.
Read-only discovery for a finite, offline-capable market briefing with explicit evidence boundaries.
Related MCP Servers
- AlicenseAqualityBmaintenanceProvides read-only investment research and audit tools for validating ETF snapshots, comparing ETF structures, and auditing backtest reports, while strictly excluding any order or trading capabilities.41MIT
- AlicenseAqualityBmaintenanceA read-only MCP server for EdgeDepth's market microstructure search engine, enabling users to query recorded crypto and TradFi perpetuals for market conditions, outcomes, and reproducibility-keyed evidence directly from MCP clients.101,033 npm3MIT
- AlicenseNot gradedqualityAmaintenanceProvides read-only MCP tools for market snapshots, position risk, order reconciliation, and daily report previews with deterministic financial calculations, evidence chains, and audit trails.MIT
