proofmarket-mcp
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": true
} |
| resources | {
"listChanged": true
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| market_stateA | Snapshot the running market: the three numbers most protocols collapse into one, plus the matching and scheduling gaps. A model, not live telemetry. |
| simulate_coordinationA | Run the proofmarket-sim engine over a full horizon for a coordination regime and return utilization and the two gaps. Same supply in every regime; only coordination changes. |
| submit_proof_requestA | A Seeker submits a Proof Request to the market. Returns a request id you can poll. The Matchmaker assigns it to a Prover Node when capacity is free. |
| poll_proofA | Check a Proof Request. When it settles, the result carries a proof id and attestation, delivered the way Fermah returns a proof to a Seeker callback URL. Zero humans involved. |
| compose_workflowA | The agentic path: define an ordered sequence and the surface runs the whole thing, no human in the loop. Steps: observe a condition, request_proof, act, settle. Returns an attested trace. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
| about | What this MCP surface is and is not |
TDQS
Scored across 5 tools
Most tools have clear boundaries: submit_proof_request and poll_proof handle request lifecycle, simulate_coordination explores scenarios, and compose_workflow orchestrates. However, market_state and simulate_coordination both report utilization and gaps, so agents could initially confuse which to use for current market health vs. hypothetical coordination regimes.
The set is mostly verb_noun (simulate_coordination, submit_proof_request, poll_proof, compose_workflow), but market_state breaks the pattern as a noun phrase rather than get_market_state, creating minor inconsistency.
Five tools is appropriate for the server's focus on market analysis, request submission, status polling, and workflow composition. It's neither sparse nor bloated, covering the core interactions with a proof market.
The core lifecycle is covered: market state inquiry, simulation for planning, request submission, result polling, and workflow orchestration. Missing operations like canceling requests or listing historical requests are workable gaps, but the essential seeker-approval journey is represented.