Skip to main content
Glama
Floopi10

TRENCH MCP

by Floopi10
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Remote

TRENCH on Robinhood Chain - market tools for AI agents

TRENCH MCP

Check liquidity before you trust the number.

TRENCH gives an AI agent observed Robinhood Chain pool data and a transparent, position-size-aware pressure model. The agent gets evidence to explain — not a made-up executable quote.

Try the browser model · Connect your agent · Read the assumptions

CI Node License

Understand it in 20 seconds

Question

Answer

What does it do?

Reads token pools and models how a USD position size changes estimated exit pressure.

Where is the AI?

Your MCP-compatible AI client calls the tools and interprets their structured results. The pressure calculation is deterministic.

Can I try it immediately?

Yes. The browser playground takes manual liquidity, position and volume inputs — no account or wallet connection.

Where does live data happen?

The remote or local MCP server reads public DexScreener pools and Robinhood Chain RPC. The website playground is not a live token scanner.

Does it execute trades?

No signing, approvals, swaps or custody. It does not look up your wallet balance.

Is the result a quote?

No. It is a disclosed constant-product proxy, not a complete Uniswap v4 execution simulation.

Actual browser pressure playground with manual inputs

Related MCP server: loxcorp

The problem

AI agents can summarize token pages, read contracts and repeat social posts. That does not answer the operational question a trader actually has:

If this position had to exit now, what does the visible market structure suggest?

Raw liquidity alone is not enough. A $50K position and a $500 position do not face the same market. TRENCH collects the token, position size, observed primary pool, RPC block and an explicit pressure model in one structured MCP result. Pool data and RPC block reads are separate observations, not an atomic block-pinned snapshot.

What TRENCH is

TRENCH is a real, local-first MCP server for Claude, Codex and any compatible client. It exposes five read-only tools backed by current Robinhood Chain RPC and pool observations.

It does not trade. It does not accept private keys. It does not pretend a constant-product model is an executable quote.

user question
     │
     ▼
AI agent ──MCP/HTTP or stdio──► TRENCH
                         ├── Robinhood Chain RPC: chain + block
                         ├── DexScreener: pools + liquidity + volume
                         └── SLIP engine: size-aware pressure model
                                      │
                                      ▼
                           evidence + grade + limits

Run it now

Requirements: Node.js 22+.

npx --yes github:Floopi10/trench-mcp

Or install locally:

git clone https://github.com/Floopi10/trench-mcp.git
cd trench-mcp
npm ci
npm start

Connect your agent

Remote HTTPS — no local installation

Add this URL to a client supporting MCP Streamable HTTP:

https://trench-mcp.mytodofloopi.workers.dev/mcp

No authentication is required for these public read-only tools. Start with chain_health, then ask for inspect_token using a public token address. The website's separate Terminal is a manual calculator; it is not the remote MCP server.

The hosted endpoint is rate limited (per-IP, best effort), limits request bodies to 16 KiB, validates browser origins, and only queries configured public data providers. It does not accept arbitrary RPC URLs or credentials from callers. Availability and provider coverage are not guaranteed. Do not send secrets.

Local stdio

After installing locally, add it to an MCP-compatible client:

{
  "mcpServers": {
    "trench": {
      "command": "node",
      "args": ["/absolute/path/to/trench-mcp/bin/trench-mcp.mjs"]
    }
  }
}

Windows example:

{
  "mcpServers": {
    "trench": {
      "command": "node",
      "args": ["C:\\tools\\trench-mcp\\bin\\trench-mcp.mjs"]
    }
  }
}

Tool surface

inspect_token

Reads the strongest visible Robinhood Chain pool for a token and returns price, liquidity, 24-hour volume, activity, pool count and a small-position pressure grade.

{ "token": "0x0000000000000000000000000000000000000000" }

simulate_exit

Models a specific USD exit size against estimated quote-side depth. The result includes the DEEP, THIN or CRITICAL grade, estimated receive, pressure percentage and suggested chunks.

{
  "token": "0x0000000000000000000000000000000000000000",
  "sizeUsd": 2500
}

compare_exit_sizes

Compares up to eight position sizes against the same market observation, preventing time drift between scenarios.

{
  "token": "0x0000000000000000000000000000000000000000",
  "sizesUsd": [100, 500, 2500, 10000]
}

chain_health

Returns chain ID, latest block, public RPC URL and observed round-trip latency.

{}

explain_exit_signal

Packages the deterministic grade into evidence, limitations and concrete next checks so the host AI can explain a result without inventing a story.

How the pressure model works

TRENCH uses the highest-liquidity observed pool and approximates quote-side depth as half of total pool liquidity. After a configurable fee assumption, it applies constant-product movement to estimate how much pressure a position introduces.

quote_depth = pool_liquidity / 2
after_fee   = size × (1 - fee_rate)
receive     = quote_depth × after_fee / (quote_depth + after_fee)
impact      = 1 - receive / after_fee

Current grade rules:

Grade

Rule

Meaning

CRITICAL

liquidity below $10K, or size above 8% of estimated quote depth

visible depth is highly constrained

THIN

size above 2% of quote depth, or 24h turnover below 5%

exit pressure deserves caution

DEEP

none of the walls above are crossed

position is small relative to the observed depth

These are transparent product rules, not predictions. Read MODEL.md for assumptions and failure modes.

Agent behavior contract

TRENCH returns facts and boundaries together. A good agent should:

  1. State the observation time and available RPC block; do not imply the pool was read at that exact block.

  2. Name the selected pool and visible liquidity.

  3. Tie the grade to the requested position size.

  4. Label modeled impact as a proxy.

  5. Recommend checking an executable venue quote before action.

A bad agent hides timestamps, calls the proxy guaranteed output, or converts a grade into financial advice.

Security boundary

  • Every MCP capability is annotated read-only.

  • EVM addresses and USD sizes are strictly validated.

  • Position size is capped at $10,000,000.

  • Network requests time out after eight seconds.

  • No secrets are accepted, logged or persisted.

  • No wallet connection, signing, approval, swap or custody code exists.

  • Diagnostics use stderr so stdout remains valid MCP framing.

See SECURITY.md for the threat model.

Documentation

Development

npm ci
npm run check
npm run inspect

npm run check validates syntax and runs unit plus real stdio MCP integration tests. npm run inspect opens the official MCP Inspector.

Current scope

Version 0.1.0 intentionally does one job well: convert current market structure into evidence an AI agent can inspect and explain. Historical monitoring, deployer tracing and executable venue routing are not implemented. They will not be implied in copy until they exist and can be verified.

Mascot

Trench is a terminal-green chibi axolotl carrying a market scanner. The axolotl fits the product: it stays calm in hostile environments, sees what is happening below the surface and does not press the trade button for you.

Pixel field notes

The main mascot stays a terminal-green pixel axolotl. These companion illustrations add personality without turning the product interface into a toy.

What is tested

npm run check runs syntax checks and the test suite, including real stdio MCP integration tests, 108 synthetic browser/server model comparisons, HTTP MCP integration, origin checks, body limits and rate-limit checks.

Tests verify implementation behavior. They do not certify a token, guarantee provider availability, or make the modeled proceeds executable. Live results can change between requests.

License

MIT

Available Tools

5 tools
chain_healthCheck Robinhood Chain healthA
Read-onlyIdempotent

Read chain ID, latest block and RPC latency without connecting a wallet.

ParametersJSON Schema
NameRequiredDescriptionDefault

No parameters

TDQS

A4/5.0
Behavior4/5

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

Annotations already establish readOnlyHint, idempotentHint, openWorldHint, and destructiveHint=false, so safety is covered. The description adds genuinely new behavioral context not in the annotations: the call requires no wallet/authentication, which tells the agent it can run this before any connection step.

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?

One sentence, front-loaded with the verb and the returned data, with no filler. Every clause earns its place.

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?

With no input parameters and no output schema, the description must carry the return-value burden itself, and it does by listing the three fields returned. Annotations cover the safety profile, so nothing an agent needs to invoke this correctly is missing.

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 takes zero parameters, so the baseline is 4. There is nothing for the description to disambiguate, and the schema is empty by design.

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 names a specific verb ('Read') and enumerates the exact resources returned: chain ID, latest block, and RPC latency. This clearly separates it from the token- and exit-oriented siblings, though it never explicitly names an alternative tool.

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?

'Without connecting a wallet' implies this is the lightweight, pre-flight check to run before anything requiring authentication, but the description never states when to prefer it over inspect_token or the simulate_* tools. Usage is inferable rather than stated.

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

compare_exit_sizesCompare exit sizesB
Read-onlyIdempotent

Compare 1 to 8 USD exit sizes against the same observed primary pool.

ParametersJSON Schema
NameRequiredDescriptionDefault
tokenYes
sizesUsdYes

TDQS

B3.3/5.0
Behavior3/5

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

Annotations already declare readOnlyHint, idempotentHint, openWorldHint and destructiveHint=false, so safety is covered. The description adds one useful behavioral fact — all sizes are measured against the same observed pool, giving a consistent baseline — but says nothing about what 'exit' means, latency, or result semantics. Adequate but thin given the low annotation burden.

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?

A single front-loaded sentence with no filler. Every clause (count, unit, resource, baseline pool) carries information.

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 2-parameter domain tool with no output schema, the definition leaves key gaps: what the 'observed primary pool' is, how results are expressed, and what the token identifies. It is minimally sufficient to invoke but not to interpret.

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 coverage is 0%, so the description carries the load. It clarifies sizesUsd ('1 to 8 USD exit sizes') and matches the minItems/maxItems bounds, but says nothing about the required 'token' address, leaving half the parameters semantically unexplained.

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?

States a specific verb (compare) and resource (USD exit sizes) with an explicit scope of 1 to 8 sizes against 'the same observed primary pool'. It is distinguishable in substance from siblings like simulate_exit, though it never names an alternative to sharpen the contrast.

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?

There is no when-to-use or when-not guidance and no alternative is named. The agent can infer that this is for comparison, but nothing tells it why to pick this over simulate_exit or explain_exit_signal.

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

explain_exit_signalExplain an exit signalC
Read-onlyIdempotent

Turn the deterministic DEEP, THIN or CRITICAL signal into evidence and next checks an AI agent can explain.

ParametersJSON Schema
NameRequiredDescriptionDefault
tokenYes
sizeUsdYes

TDQS

C2.7/5.0
Behavior3/5

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

Annotations already declare read-only, idempotent, open-world, and non-destructive behavior, so the safety profile is covered. The description adds that the signal is deterministic and that output is 'evidence and next checks,' which is modest extra context, but it does not disclose thresholds, rate limits, or what a response contains.

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?

A single tight sentence with no filler, and the core action is front-loaded. It is efficient, though the compressed jargon (DEEP/THIN/CRITICAL) trades clarity for brevity.

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

Completeness2/5

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

With no output schema, 0% parameter coverage, and unexplained signal categories, the description leaves major gaps: what input produces the signal, what 'evidence' is returned, and what the next checks look like. The internal vocabulary is never defined, so an agent lacks enough to call or interpret the tool confidently.

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 description coverage is 0%, so the description carries the full burden, and it says nothing about the two parameters. It does not clarify that 'token' is a 0x contract address nor that 'sizeUsd' is a position size bounded at 10,000,000 USD, leaving both inputs semantically undefined.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose3/5

Does the description clearly state what the tool does and how it differs from similar tools?

The verb ('turn ... into evidence and next checks') and resource ('the DEEP, THIN or CRITICAL signal') are stated, so the general intent is inferable. But the description never explains where that signal comes from, what DEEP/THIN/CRITICAL mean, or how it differs from siblings like simulate_exit or compare_exit_sizes. Vague purpose with no sibling differentiation.

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?

There is no when-to-use guidance, no when-not-to-use, and no reference to any alternative tool. An agent cannot tell from this text why it would call explain_exit_signal rather than simulate_exit, compare_exit_sizes, or inspect_token.

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

inspect_tokenInspect a Robinhood Chain tokenB
Read-onlyIdempotent

Read current pools, liquidity, volume, price and a small-position exit grade.

ParametersJSON Schema
NameRequiredDescriptionDefault
tokenYes

TDQS

B3/5.0
Behavior3/5

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

Annotations already declare readOnlyHint, idempotentHint, openWorldHint, and destructiveHint=false, so the safety profile is covered. The description adds only that it computes a 'small-position exit grade', with no mention of data freshness, chain coverage, or cost; given the annotation coverage this is a marginal but acceptable contribution.

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?

A single front-loaded sentence with no filler; the read verb leads and the returned data follows. It is efficient, though its brevity is arguably part of why the behavioral and parameter gaps exist.

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?

With no output schema, the description usefully enumerates what is returned (pools, liquidity, volume, price, exit grade). But for a tool requiring an address argument it omits the parameter's meaning and format and gives no sense of how results relate to the sibling exit tools, leaving the definition only minimally sufficient.

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 description coverage is 0% for the single required 'token' parameter, and the description never explains it. The address format (0x + 40 hex) and the fact it must be a Robinhood Chain token come only from the title/pattern, not the description, so compensation for the coverage gap is essentially absent.

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 names a specific verb (Read) and a concrete set of resources (pools, liquidity, volume, price, exit grade) for a token, so an agent knows exactly what comes back. It does not, however, distinguish this from the exit-oriented siblings (simulate_exit, compare_exit_sizes, explain_exit_signal), which overlap on the 'exit grade' concept.

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?

There is no guidance on when to call inspect_token versus simulate_exit, compare_exit_sizes, or explain_exit_signal. Usage is only implied by the word 'Read', leaving the agent to infer that this is the snapshot/read step that precedes the other exit tools.

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

simulate_exitSimulate token exit pressureA
Read-onlyIdempotent

Estimate exit pressure for a USD position using current Robinhood Chain market data. This is a proxy, not an executable quote.

ParametersJSON Schema
NameRequiredDescriptionDefault
tokenYes
sizeUsdYes

TDQS

A3.5/5.0
Behavior4/5

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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive, open-world), so the description's added value is the disclaimer that this is a proxy estimate, not an executable quote, plus the implied dependency on live market data. That is genuinely useful interpretive context beyond the structured fields, though nothing is said about freshness, rate limits, or error behavior.

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 tight sentences with the core action front-loaded and the important caveat immediately after. Every sentence earns its place; there is 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?

For a read-only simulation tool, the description covers purpose, data source, and the proxy caveat, and annotations cover safety. However, with no output schema, the description never indicates what the estimate looks like or what drives it, leaving the agent guessing about the return shape.

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 0%, so the description must carry the load. It partially does: 'USD position' clarifies that sizeUsd is a USD-denominated notional, but 'token' is left to the schema's address pattern alone and no format or range guidance is added. The schema's own pattern and min/max constraints do much of the work.

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 gives a specific verb (estimate) and resource (exit pressure for a USD position) and names the data source (current Robinhood Chain market data), so the agent knows exactly what the tool computes. It does not contrast itself against close siblings like compare_exit_sizes or explain_exit_signal, so it falls short of the top mark.

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?

There is no explicit when-to-use guidance and no mention of alternatives, despite three closely related siblings. The only hint is the caveat that the result is a proxy rather than an executable quote, which clarifies output nature but not when to pick this tool over compare_exit_sizes or explain_exit_signal.

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. 5 tool updatesv0.1.0
    • First observedchain_health
    • First observedcompare_exit_sizes
    • First observedexplain_exit_signal
    • First observedinspect_token
    • First observedsimulate_exit
Deploy Server
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A3.5/5.0

Scored across 5 tools

Disambiguation4/5

Each tool has a largely distinct focus: inspect_token reads raw market state, simulate_exit estimates pressure for one position, compare_exit_sizes sweeps multiple sizes, chain_health checks infrastructure, and explain_exit_signal narrates the signal. There is mild overlap between inspect_token's 'exit grade' and the signal-based tools, and simulate_exit vs compare_exit_sizes target the same concern at different granularities, but descriptions make the split workable.

Naming Consistency4/5

Names are uniformly snake_case and mostly follow a verb_noun pattern (inspect_token, simulate_exit, compare_exit_sizes, explain_exit_signal). chain_health breaks the pattern by being noun-only, a minor deviation that remains clear and readable.

Tool Count5/5

Five tools is well-scoped for a focused exit-pressure analysis server, with each tool earning a distinct role (inspect, simulate, compare, infra check, explain). No redundancy or bloat.

Completeness4/5

The read-only analysis lifecycle is well covered: token state, single and multi-size exit simulation, chain health, and signal explanation. Minor gaps exist—no token discovery/listing or cross-token comparison—but the stated exit-analysis purpose is largely served without dead ends.

Maintenance

ActivityMaintained
ResponsivenessNo issues

Resources

Related MCP Connectors

Related MCP Servers

  • robinhood-chain-mcp

    arambarnett
    A
    license
    A
    quality
    B
    maintenance
    Enables agents to query live Robinhood Chain data including tokens, wallets, Chainlink feeds, heat scores, and tracking error on tokenized equities, all read-only without API keys.
    4
    4
    MIT

  • loxcorp

    loxcorp
    A
    license
    Not graded
    quality
    C
    maintenance
    Provides live, read-only access to Robinhood Chain and Lox Corp data, enabling AI agents to query chain stats, token launches, agent details, and more.
    10
    1
    MIT

  • orderbook-depth

    Br0ski777
    A
    license
    Not graded
    quality
    B
    maintenance
    Enables AI agents to analyze Uniswap V3 pool liquidity depth and estimate price impact at 1%, 2%, 5%, and 10% levels before large trades, with pay-per-call micropayments via x402.
    MIT