Which integrations are available for this server?

Provides read-only access to infiniFi protocol state on Ethereum mainnet through JSON-RPC eth_call. It can query token supplies for iUSD and siUSD, list registered farms and enabled assets, and retrieve individual farm state including asset token, assets, and cap.

How do I use infiniFi MCP Server?

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., "@infiniFi MCP Server what are the current iUSD and siUSD token supplies?" 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.

infiniFi MCP Server

by MarvelNwachukwu

Overview Schema Source Related Servers Discussions Admin

TypeScript

Remote

mcp-infinifi

Read-only stdio MCP server for infiniFi public Ethereum mainnet contracts and documentation index. No wallet, key, transaction signing, authentication, or write tools. This is an independent local prototype, not an infiniFi release.

The API documentation names protocol state and historical data but publishes no HTTP paths, parameters, or base URL. It points to an infinifi-backend repository that returned HTTP 404 when checked on 2026-10-20. This server does not invent an HTTP API, historical metric, or product endpoint. Instead it uses eth_call against published Ethereum contract addresses, the public contract interfaces, and the published llms.txt index.

Install

Node.js 20+ and pnpm are required. From this folder:

pnpm install
pnpm build
node dist/index.js

The last command runs the stdio server; an MCP client supplies messages on stdin. Set INFINIFI_RPC_URL to another trusted Ethereum mainnet JSON-RPC URL if the default public endpoint is unavailable. The default is https://ethereum-rpc.publicnode.com.

For Claude Desktop on macOS, add this to ~/Library/Application Support/Claude/claude_desktop_config.json under mcpServers and restart Claude:

{
  "mcpServers": {
    "infinifi": {
      "command": "node",
      "args": [
        "/Users/0xmarvel/superconductor/projects/value-drops/infinifi-mcp/dist/index.js"
      ]
    }
  }
}

For Cursor, use the same mcpServers entry in ~/.cursor/mcp.json (or the project .cursor/mcp.json) and reload Cursor. Replace the path if you moved this folder.

Related MCP server: Cryo MCP

Tool to source mapping

Tool	Exact read	Public source
`get_token_supplies`	JSON-RPC `eth_call`: `totalSupply()`, `decimals()` on iUSD and siUSD	Token addresses, ReceiptToken, StakedToken
`list_registered_farms`	JSON-RPC `eth_call`: `getFarms()`, `getEnabledAssets()` on FarmRegistry	Registry address, source
`get_farm_state`	JSON-RPC `eth_call`: `isFarm(address)`, then `assetToken()`, `assets()`, `cap()`, asset `decimals()`	Registry, Farm source
`get_docs_index`	HTTP `GET https://docs.infinifi.xyz/llms.txt`	Documentation index

Each onchain result reads a single block. retrievedAt is local request completion time, not the block time. Amounts remain decimal strings, with raw integer values included. A capUnlimited flag marks the contract uint256.max sentinel, with cap: null. Token supply is not TVL; farm accounting assets are not a promise of immediate liquidity.

Real MCP calls

I started node dist/index.js over stdio, initialized MCP, and sent the following tools/call requests on 2026-10-20 UTC. The JSON below is the exact text returned by each tool at that time. Values will change.

get_token_supplies

Request: tools/call with {"name":"get_token_supplies","arguments":{}}.

Recorded tool text (live response):

{
  "readOnly": true,
  "retrievedAt": "2026-10-20T20:32:25.412Z",
  "source": {
    "endpoint": "https://ethereum-rpc.publicnode.com eth_call",
    "methods": "iUSD.totalSupply(), iUSD.decimals(), siUSD.totalSupply(), siUSD.decimals()",
    "contracts": [
      "0x48f9e38f3070AD8945DFEae3FA70987722E3D89c",
      "0xDBDC1Ef57537E34680B898E1FEBD3D68c7389bCB"
    ],
    "documentation": "https://docs.infinifi.xyz/dev-docs/contracts",
    "interfaces": [
      "https://github.com/InfiniFi-Labs/infinifi-protocol/blob/master/src/tokens/ReceiptToken.sol",
      "https://github.com/InfiniFi-Labs/infinifi-protocol/blob/master/src/tokens/StakedToken.sol"
    ]
  },
  "data": {
    "block": "26236205",
    "tokens": [
      {
        "symbol": "iUSD",
        "address": "0x48f9e38f3070AD8945DFEae3FA70987722E3D89c",
        "supplyRaw": "68302862178713469460186700",
        "decimals": 18,
        "supply": "68302862.1787134694601867"
      },
      {
        "symbol": "siUSD",
        "address": "0xDBDC1Ef57537E34680B898E1FEBD3D68c7389bCB",
        "supplyRaw": "48068711238339140960628049",
        "decimals": 18,
        "supply": "48068711.238339140960628049"
      }
    ]
  }
}

list_registered_farms

Request: tools/call with {"name":"list_registered_farms","arguments":{}}.

Recorded tool text (live response):

{
  "readOnly": true,
  "retrievedAt": "2026-10-20T20:32:26.018Z",
  "source": {
    "endpoint": "https://ethereum-rpc.publicnode.com eth_call",
    "contract": "0xF5f2718708f471e43968271956CC01aaA8c46119",
    "methods": "getFarms(), getEnabledAssets()",
    "documentation": "https://docs.infinifi.xyz/dev-docs/integrations/farm-registry",
    "interface": "https://github.com/InfiniFi-Labs/infinifi-protocol/blob/master/src/integrations/FarmRegistry.sol"
  },
  "data": {
    "block": "26236205",
    "count": 17,
    "farms": [
      "0x49877d937B9a00d50557bdC3D87287b5c3a4C256",
      "0xCb1747E89a43DEdcF4A2b831a0D94859EFeC7601",
      "0xda40ce7DdDBE7D54A106D32575b2CCF41dDb1A11",
      "0xAc21B22B5aEb11bc32De4ecF59E4538fCa48b694",
      "0x90787c1b99F47EFfEE0db0aB9D4e33CdC3e6bFa7",
      "0x79e1B8e45932A7C802eA3dAb3844e5DEa68d971f",
      "0x277FdF6Dc5c53C5c2828188Da84B9593A50884C1",
      "0xe919C66475f2F30d285c768853E6B5b23ef181Cf",
      "0xbFd5FC8DecA3C6128bfCE0FE46c25616811c3580",
      "0xfD1Ea12d29B90630b265DBbc6Af88266d1a83dE4",
      "0xd880D7C5CaFdbE2AEc281250995abF612235e563",
      "0xA7c1DAEAA5D97e1319B4Ff6Cdf658F5C4582A27E",
      "0x9E5efC5F387D8661C1AFB2469B7EeF6972451852",
      "0x2fa5E6C5549BEdF98A935Cac3BB4337459c74897",
      "0x78A31bD6cAca12BdF83F8A608076006C1F58F363",
      "0xbD6c2d1C4809a5D8847FbA3a3cf7d6BDf6b6C3bA",
      "0xe9E44C0A68C49aDe51CdA5e027909C5996B5c71a"
    ],
    "enabledAssets": [
      "0xA0b86991c6218b36c1d19D4a2e9Eb0cE3606eB48",
      "0x8292Bb45bf1Ee4d140127049757C2E0fF06317eD"
    ]
  }
}

get_farm_state

Request: tools/call with {"name":"get_farm_state","arguments":{"address":"0xbFd5FC8DecA3C6128bfCE0FE46c25616811c3580"}}.

Recorded tool text (live response):

{
  "readOnly": true,
  "retrievedAt": "2026-10-20T20:32:32.937Z",
  "source": {
    "endpoint": "https://ethereum-rpc.publicnode.com eth_call",
    "contract": "0xbFd5FC8DecA3C6128bfCE0FE46c25616811c3580",
    "methods": "FarmRegistry.isFarm(address), Farm.assetToken(), Farm.assets(), Farm.cap(), assetToken.decimals()",
    "registry": "0xF5f2718708f471e43968271956CC01aaA8c46119",
    "documentation": "https://docs.infinifi.xyz/dev-docs/integrations/farm-registry",
    "interface": "https://github.com/InfiniFi-Labs/infinifi-protocol/blob/master/src/integrations/Farm.sol"
  },
  "data": {
    "block": "26236205",
    "address": "0xbFd5FC8DecA3C6128bfCE0FE46c25616811c3580",
    "assetToken": "0xA0b86991c6218b36c1d19D4a2e9Eb0cE3606eB48",
    "decimals": 6,
    "assetsRaw": "3508611028172",
    "assets": "3508611.028172",
    "capRaw": "115792089237316195423570985008687907853269984665640564039457584007913129639935",
    "cap": null,
    "capUnlimited": true
  }
}

get_docs_index

Request: tools/call with {"name":"get_docs_index","arguments":{}}.

Recorded tool text (live response):

{
  "readOnly": true,
  "retrievedAt": "2026-10-20T20:32:33.223Z",
  "source": {
    "endpoint": "GET https://docs.infinifi.xyz/llms.txt",
    "documentation": "https://docs.infinifi.xyz/dev-docs/api-documentation"
  },
  "data": {
    "pages": [
      {
        "title": "infiniFi Docs Hub",
        "url": "https://docs.infinifi.xyz/index.md"
      },
      {
        "title": "Whitepaper",
        "url": "https://docs.infinifi.xyz/whitepaper/index.md"
      },
      {
        "title": "Oracles",
        "url": "https://docs.infinifi.xyz/oracles.md"
      },
      {
        "title": "Vaults",
        "url": "https://docs.infinifi.xyz/vaults.md"
      },
      {
        "title": "Deposit Quickstart",
        "url": "https://docs.infinifi.xyz/deposit-quickstart.md"
      },
      {
        "title": "Pendle Liquidity Transfer",
        "url": "https://docs.infinifi.xyz/pendle-liquidity-transfer/index.md"
      },
      {
        "title": "Security",
        "url": "https://docs.infinifi.xyz/audits.md"
      },
      {
        "title": "Risk Disclosures",
        "url": "https://docs.infinifi.xyz/risk-disclosures.md"
      },
      {
        "title": "Slashing mechanics",
        "url": "https://docs.infinifi.xyz/slashing-mechanics.md"
      },
      {
        "title": "Developer Summary",
        "url": "https://docs.infinifi.xyz/dev-docs/summary.md"
      },
      {
        "title": "Contract Addresses",
        "url": "https://docs.infinifi.xyz/dev-docs/contracts.md"
      },
      {
        "title": "Changelog",
        "url": "https://docs.infinifi.xyz/dev-docs/changelog.md"
      },
      {
        "title": "Core",
        "url": "https://docs.infinifi.xyz/dev-docs/core/index.md"
      },
      {
        "title": "InfiniFiCore.sol",
        "url": "https://docs.infinifi.xyz/dev-docs/core/infini-fi-core.md"
      },
      {
        "title": "CoreControlled.sol",
        "url": "https://docs.infinifi.xyz/dev-docs/core/core-controlled.md"
      },
      {
        "title": "Gateway",
        "url": "https://docs.infinifi.xyz/dev-docs/gateway/index.md"
      },
      {
        "title": "InfiniFiGatewayV1.sol",
        "url": "https://docs.infinifi.xyz/dev-docs/gateway/infini-fi-gateway-v1.md"
      },
      {
        "title": "Tokens",
        "url": "https://docs.infinifi.xyz/dev-docs/tokens/index.md"
      },
      {
        "title": "ReceiptToken.sol",
        "url": "https://docs.infinifi.xyz/dev-docs/tokens/receipt-token.md"
      },
      {
        "title": "StakedToken.sol",
        "url": "https://docs.infinifi.xyz/dev-docs/tokens/staked-token.md"
      },
      {
        "title": "LockedPositionToken.sol",
        "url": "https://docs.infinifi.xyz/dev-docs/tokens/locked-position-token.md"
      },
      {
        "title": "Funding",
        "url": "https://docs.infinifi.xyz/dev-docs/funding/index.md"
      },
      {
        "title": "MintController.sol",
        "url": "https://docs.infinifi.xyz/dev-docs/funding/mint-controller.md"
      },
      {
        "title": "RedeemController.sol",
        "url": "https://docs.infinifi.xyz/dev-docs/funding/redeem-controller.md"
      },
      {
        "title": "RedemptionPool.sol",
        "url": "https://docs.infinifi.xyz/dev-docs/funding/redemption-pool.md"
      },
      {
        "title": "Locking",
        "url": "https://docs.infinifi.xyz/dev-docs/locking/index.md"
      },
      {
        "title": "LockingController.sol",
        "url": "https://docs.infinifi.xyz/dev-docs/locking/locking-controller.md"
      },
      {
        "title": "UnwindingModule.sol",
        "url": "https://docs.infinifi.xyz/dev-docs/locking/unwinding-module.md"
      },
      {
        "title": "Finance",
        "url": "https://docs.infinifi.xyz/dev-docs/finance/index.md"
      },
      {
        "title": "Accounting.sol",
        "url": "https://docs.infinifi.xyz/dev-docs/finance/accounting.md"
      },
      {
        "title": "YieldSharing.sol",
        "url": "https://docs.infinifi.xyz/dev-docs/finance/yield-sharing.md"
      },
      {
        "title": "Governance",
        "url": "https://docs.infinifi.xyz/dev-docs/governance/index.md"
      },
      {
        "title": "AllocationVoting.sol",
        "url": "https://docs.infinifi.xyz/dev-docs/governance/allocation-voting.md"
      },
      {
        "title": "Timelock.sol",
        "url": "https://docs.infinifi.xyz/dev-docs/governance/timelock.md"
      },
      {
        "title": "MinorRolesManager.sol",
        "url": "https://docs.infinifi.xyz/dev-docs/governance/minor-roles-manager.md"
      },
      {
        "title": "Integrations",
        "url": "https://docs.infinifi.xyz/dev-docs/integrations/index.md"
      },
      {
        "title": "Farm.sol",
        "url": "https://docs.infinifi.xyz/dev-docs/integrations/farm.md"
      },
      {
        "title": "FarmRegistry.sol",
        "url": "https://docs.infinifi.xyz/dev-docs/integrations/farm-registry.md"
      },
      {
        "title": "Farms",
        "url": "https://docs.infinifi.xyz/dev-docs/integrations/farms.md"
      },
      {
        "title": "API Documentation",
        "url": "https://docs.infinifi.xyz/dev-docs/api-documentation.md"
      },
      {
        "title": "Roles Documentation",
        "url": "https://docs.infinifi.xyz/dev-docs/roles-documentation.md"
      },
      {
        "title": "Research Overview",
        "url": "https://docs.infinifi.xyz/research.md"
      },
      {
        "title": "Liquid keeper reserve",
        "url": "https://docs.infinifi.xyz/liquid-keeper-reserve.md"
      },
      {
        "title": "Risk Assessment Framework",
        "url": "https://docs.infinifi.xyz/risk-assessment-framework.md"
      }
    ]
  }
}

What I would add next

Once infiniFi publishes concrete public HTTP paths and schemas, add protocol-state and historical-metric tools against those documented endpoints. Cross-check farm valuations against a published accounting contract address before calling any aggregate figure TVL.

Available Tools

4 tools

get_docs_indexA

Fetch infiniFi's live llms.txt index of canonical documentation URLs. Returns titles and URLs, not scraped protocol metrics.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A4.2/5.0

Behavior3/5

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

No annotations are provided, so the description carries the burden. It discloses that the index is 'live' and that the response contains titles and URLs rather than metrics, which is meaningful return-shape context. It says nothing about auth requirements, rate limits, or caching freshness beyond 'live,' so it is adequate but not rich.

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 zero filler; the identity of the resource is front-loaded and the exclusion clause follows immediately. Every clause earns its place.

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?

With zero parameters and no output schema, the description partially compensates by describing the return shape (titles and URLs, not metrics). That gives the agent enough to invoke the tool correctly, though a note on freshness or scope limits would round it out.

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 schema takes zero parameters, which sets the baseline at 4. There is nothing for the description to clarify beyond confirming the tool takes no input, which it implicitly does.

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 (Fetch) and resource (infiniFi's live llms.txt index of canonical documentation URLs). It explicitly excludes the metric-style content of its siblings with 'not scraped protocol metrics,' so an agent can distinguish it from get_token_supplies, list_registered_farms, and get_farm_state without opening any schema.

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 phrase 'not scraped protocol metrics' functions as a clear when-not signal that routes the agent away from the metrics siblings and toward this tool for URL discovery. It stops short of naming an explicit alternative or prerequisite, so it falls just below the top band.

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

get_farm_stateA

Read a registered Ethereum mainnet farm's asset token, accounting assets and deposit cap at one block. capUnlimited=true means no configured cap; accounting assets are not guaranteed instantly redeemable.

ParametersJSON Schema

Name	Required	Description	Default
`address`	Yes	Registered Ethereum mainnet farm address

TDQS

A3.8/5.0

Behavior3/5

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

No annotations are provided, so the description carries the full burden. It usefully explains capUnlimited semantics and that accounting assets are not guaranteed instantly redeemable, but omits permission requirements, failure modes, and whether the call is strictly read-only beyond the verb 'Read'.

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, front-loaded with the read action and fields, followed by the two important caveats. No wasted words.

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?

With no output schema and no annotations, the description lists the returned fields (asset token, accounting assets, deposit cap) and clarifies capUnlimited and redeemability. It could be more explicit about the return structure/formats, but is nearly complete for a one-parameter read.

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 100%: the sole address parameter is fully documented in the schema with a pattern and meaning. The description adds no parameter syntax or format details beyond restating that it must be a registered Ethereum mainnet farm address.

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 states a specific verb (Read) and resource (a registered Ethereum mainnet farm's asset token, accounting assets, deposit cap) with the scope 'at one block'. It distinguishes from siblings like list_registered_farms and get_token_supplies by focusing on one farm's state rather than listing farms or token supplies.

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?

Implied usage for inspecting a registered mainnet farm's state. It does not explicitly state when to use this vs list_registered_farms or get_token_supplies, nor any preconditions beyond 'registered Ethereum mainnet farm'.

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

get_token_suppliesA

Read Ethereum mainnet iUSD and siUSD ERC-20 total supplies at one block. Supplies are not protocol TVL.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A4.2/5.0

Behavior3/5

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

With no annotations, the description carries the full behavioral burden. It conveys read-only access and specifies the chain and token scope, but it does not state whether the block is latest, how failures are surfaced, or what the return shape looks like. For a zero-parameter read this is adequate but not rich.

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 short sentences, front-loaded with the core action and followed by the key semantic caveat. No wasted words.

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?

Given a zero-parameter read with no output schema or annotations, the description covers what is read, on which chain, for which tokens, and what the values do not represent. The only mild gap is that 'at one block' is not further specified, but with no block parameter available there is little more the description could clarify.

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 there are no parameter semantics to explain and the baseline is 4. The description wisely does not invent parameter guidance and instead clarifies the data scope.

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 gives a specific verb, resource, and scope: read Ethereum mainnet iUSD and siUSD ERC-20 total supplies at one block. It is immediately distinguishable from the sibling farm and docs tools, which cover entirely different resources.

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?

It clearly frames the tool as a read for token supplies and warns that supplies are not protocol TVL, which prevents a common misuse. It does not name alternatives or state explicit when-not-to-use conditions beyond that caveat, but the sibling tools are far enough apart that no direct alternative is needed.

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

list_registered_farmsA

Read all registered Ethereum mainnet farm addresses and enabled asset addresses at one block; does not infer current yield or liquidity.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A3.7/5.0

Behavior3/5

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

With no annotations, the description carries the full disclosure burden. It usefully states this is a read-only snapshot ('at one block') and declares what it does not compute (yield, liquidity), but it says nothing about permissions, freshness/staleness of the block, or whether the set can change between calls.

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 tightly constructed sentence with the resource and scope front-loaded, followed by an appended negative constraint. Every clause carries information and none is wasted.

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?

For a parameterless read with no output schema and no annotations, the description adequately conveys the returned domain (farm addresses and enabled asset addresses) and the excluded domain (yield, liquidity). Only the shape/format of the response is left unstated, which is a minor gap for a simple list.

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 schema has zero parameters, which earns the baseline 4. The description introduces a conceptual notion ('at one block') that is not represented in the schema, but since there is nothing to invoke, no parameter-level detail is missing.

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 ('Read') and a precise resource ('registered Ethereum mainnet farm addresses and enabled asset addresses'), plus a scope qualifier ('at one block'). It is clear on its own, but it never names or contrasts with its siblings (get_farm_state, get_token_supplies), so an agent must infer the distinction rather than being told.

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?

There is no explicit when-to-use or when-to-choose-an-alternative statement, but 'does not infer current yield or liquidity' functions as an implicit boundary, steering agents away from expecting analytics. The sibling that would actually serve those needs (get_farm_state) is never mentioned, so guidance remains implied rather than actionable.

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.

4 tool updatesv0.1.0Oct 20, 2026
- First observedget_docs_index
- First observedget_farm_state
- First observedget_token_supplies
- First observedlist_registered_farms

Deploy Server

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

TDQS

A4/5.0

Scored 2026-10-20 21:35 across 4 tools

Disambiguation5/5

Each tool targets a distinct resource and action: token supplies, farm enumeration, single-farm state, and documentation index. The descriptions explicitly delineate boundaries (e.g. list_registered_farms vs get_farm_state) so an agent can select reliably.

Naming Consistency5/5

All four tools follow a consistent verb_noun snake_case pattern: get_token_supplies, list_registered_farms, get_farm_state, get_docs_index. Verb choice (get/list) maps predictably to retrieval vs enumeration.

Tool Count4/5

Four tools is slightly thin but well-scoped for a read-only protocol data reader, with each tool earning its place. No redundant or filler tools, though the surface is minimal.

Completeness3/5

The read surface covers token supplies, farms, farm state, and docs, but lacks user-position/balance queries and yield or historical metrics that a protocol reader would typically need. These notable gaps limit deeper agent workflows without external calls.

Maintenance

ActivityMaintained

ResponsivenessNo issues

Resources

GitHub Repository

Need Help?

Related Servers

Related MCP Connectors

1NFER Inference Discovery A
business.hesoyam
Inspect 1NFER models, crypto funding terms and task cost without keys or paid calls.
AI & Machine Learning Cryptocurrency Finance
1
Prediction Market Intelligence A
markets.lacuna
Polymarket in your AI: market rules, real fill costs, who is trading, top traders. Read-only.
Finance Cryptocurrency Web3 & Decentralized Tech
71
1inch MCP A
com.1inch.business
Doc search, intent & cross-chain swaps, limit orders, portfolio, spot prices, gas & all APIs.
Cryptocurrency Finance Blockchain
1022
Ask GinaOAuth
ai.askgina
Read-only research on tokens, Hyperliquid perps, Polymarket markets and your Ask Gina account.
15

Related MCP Servers

ChainFETCH MCP Serverofficial
Vector Databases Blockchain RAG Systems
chainfetch
A
license
C
quality
D
maintenance
Enables AI-powered analysis of Ethereum blockchain data through semantic search, natural language queries, and structured filtering. Provides comprehensive access to addresses, transactions, blocks, tokens, and smart contracts with real-time blockchain intelligence.
Updated a year ago (2025-08-23 09:21 UTC)
26
6 npm
1
MIT
Cryo MCP
Blockchain Web3 & Decentralized Tech
chainbound
A
license
Not graded
quality
D
maintenance
Enables natural language querying of blockchain data, including blocks, transactions, logs, and more, powered by Cryo and Reth, with optional micropayment integration via Payflow.
Updated a year ago (2025-06-09 11:10 UTC)
8
MIT
onchain-mcp
Blockchain Cryptocurrency
sylvainlondon136
A
license
A
quality
D
maintenance
Provides read-only access to Solana on-chain data, enabling natural language queries for wallet balances, token holdings, prices, transactions, and more via MCP-compatible clients.
Updated 4 months ago (2026-06-10 16:34 UTC)
8
MIT
mcp-blockscout
Blockchain Cryptocurrency
pipeworx-io
A
license
Not graded
quality
B
maintenance
Enables querying on-chain data (balances, transactions, token transfers, blocks) across 20+ EVM chains through natural language.
Updated 25 days ago (2026-09-25 22:12 UTC)
16 npm
MIT

mcp-infinifi

Install

Tool to source mapping

Real MCP calls

get_token_supplies

list_registered_farms

get_farm_state

get_docs_index

What I would add next

Available Tools

Tool Schema Changelog

Maintenance

Resources

Related MCP Connectors

Related MCP Servers

ChainFETCH MCP Serverofficial