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., "@vfat Metrics MCP Show vfat positions for 0xd8dA6BF26964aF9D7eEd9e03E53415D37aA96045"
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.
A read-only Model Context Protocol server for querying public vfat Metrics position data by EVM address. It gives MCP clients structured access to current vfat/Sickle positions, NFT lifecycle actions, historical value and performance series, CSV exports, and a compact portfolio summary.
This is an independent community project. It is not affiliated with or endorsed by vfat, Sickle, or their contributors.
Tool | Purpose |
| Return every current position and the provider's position fields |
| Find one position by NFT/token ID |
| Count positions by chain/protocol and aggregate selected USD metrics |
| Group deposits, rebalances and other events by transaction |
| Return historical value, token balances and range state |
| Return APR, ROI, PnL and balance time series |
| Export actions, value history or performance as CSV text |
Every tool is declared read-only and idempotent. The server cannot sign messages, submit transactions, rebalance liquidity, or move funds.
Related MCP server: MTRKR MCP Server
Node.js 20 or newer
An MCP client such as Codex, Claude Desktop, or another MCP-compatible agent
Internet access to https://info-api.vf.at
No API key is required.
From a checkout:
npm install
npm run build
node dist/index.jsFor development:
npm run devThe default transport is stdio. The process writes protocol messages to stdout and diagnostics to stderr.
Build the project, then add it to ~/.codex/config.toml:
[mcp_servers.vfat_metrics]
command = "node"
args = ["/absolute/path/to/vfat-metrics-mcp/dist/index.js"]Restart Codex after changing MCP configuration. You can then ask, for example:
Show and summarize the current vfat positions for
<EVM_ADMIN_ADDRESS>.
Analyze rebalance costs and cashflows for the position identified by
<CHAIN_ID>,<SICKLE_ADDRESS>,<NFT_ID>, and<NFT_MANAGER_ADDRESS>.
{
"mcpServers": {
"vfat-metrics": {
"command": "node",
"args": ["/absolute/path/to/vfat-metrics-mcp/dist/index.js"]
}
}
}For local development or a trusted private network:
npm run build
node dist/index.js --httpMCP endpoint: http://127.0.0.1:3000/mcp
Health endpoint: http://127.0.0.1:3000/health
HTTP mode is stateless. Do not expose it publicly without authentication, TLS, request limits, and
a suitable reverse proxy. Configure it with MCP_HTTP_HOST, MCP_HTTP_PORT, or
MCP_TRANSPORT=http.
The server reads public endpoints used by the vfat Metrics website:
GET https://info-api.vf.at/open-positions-v2?admin_address=<address>
GET https://info-api.vf.at/sickle-nft-actions?...position identity...
POST https://info-api.vf.at/historical-underlying-assets
GET https://info-api.vf.at/position-performance-history?...position identity...The upstream endpoint is not documented as a stable public API and may change without notice. Raw
position fields are passed through so new fields remain available. Portfolio totals use
decimal.js; provider-supplied decimal strings are therefore summed without JavaScript binary
floating-point addition.
USD values, PnL, ROI, APR, token prices, timestamps, range state, and rewards are provider-derived estimates. They may be delayed, incomplete, or calculated differently from on-chain state. Verify material decisions independently with on-chain reads and protocol contracts.
vfat can emit several raw rows for one transaction. get_vfat_position_actions groups them by
transaction hash, selects the lifecycle action, sums provider cashflow fields with decimal
arithmetic, and retains rewards and swaps. Set include_raw_events=true when an audit needs every
provider row.
Value history follows NFT migrations and rebalances by discovering every token ID in the action
chain before requesting historical underlying assets. Points at the same timestamp are aggregated
into normalized token balances, USD values, and one in_range state.
All history tools accept optional inclusive from and to ISO 8601 timestamps. Position identity
fields are supplied at runtime and are never stored by the server.
export_vfat_position_csv accepts dataset=actions, value_history, or performance. It returns
UTF-8 CSV text plus structured metadata (filename, mime_type, and row_count). The CSV is built
from the same normalized JSON returned by the history tools, making calculations reproducible
without browser automation.
Copy .env.example values into your process environment if you need overrides:
Variable | Default | Meaning |
|
| Upstream base URL |
|
| Request timeout in milliseconds |
|
|
|
|
| HTTP bind address |
|
| HTTP port |
npm run checkThis runs formatting checks, ESLint, TypeScript typechecking, unit tests, and a production build.
Exports transaction actions, position value history or performance history as RFC-style CSV text for reproducible analysis.
| Name | Required | Description | Default |
|---|---|---|---|
| to | No | Optional inclusive ISO 8601 timestamp with timezone | |
| from | No | Optional inclusive ISO 8601 timestamp with timezone | |
| nft_id | Yes | NFT or position token ID | |
| dataset | Yes | Dataset to export | |
| chain_id | Yes | EVM chain ID | |
| nft_address | Yes | NFT position manager address | |
| sickle_address | Yes | Sickle account address |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint, idempotentHint, and destructiveHint=false. The description adds return format ('RFC-style CSV text') and dataset options, but does not disclose further behavioral traits like response size, error handling, or authentication needs. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence that front-loads the verb 'Exports' and delivers the key information without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 7 parameters and no output schema, the description states the output format (CSV text) and the three dataset types, which is reasonably complete. However, it does not detail the CSV structure or edge cases, but the dataset enum provides necessary context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with all parameters documented. The description repeats dataset options but does not add new meaning beyond the schema. Baseline 3 is appropriate since the schema handles parameter semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: exporting transaction actions, value history, or performance history as CSV text. It distinguishes itself from sibling 'get' tools by emphasizing CSV export for reproducible analysis, which differentiates it from likely JSON-returning functions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for 'reproducible analysis' but does not explicitly state when to use this tool over alternatives or provide exclusions. It lacks direct references to sibling tools or when-not-to-use scenarios, leaving the user to infer.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Returns a compact cross-chain position count, protocol breakdown, range status and provider-derived USD totals for an EVM admin address.
| Name | Required | Description | Default |
|---|---|---|---|
| admin_address | Yes | EVM admin/owner address used by vfat |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the read-only and non-destructive annotations, the description adds useful behavioral context: it is cross-chain (implying multiple network queries) and relies on a provider for USD valuations. No contradictions with annotations are present.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence without redundancy. Every word contributes to conveying the tool's purpose and output composition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description lists the returned components but does not detail the exact structure or format (e.g., how range status is represented). It is adequate for a compact summary tool but leaves some ambiguity about the response shape.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides complete documentation for the single parameter (admin_address) with pattern and description. The tool description adds no additional parameter semantics, so a baseline score of 3 is appropriate given the high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function with a specific verb ('Returns') and resource ('compact cross-chain position count, protocol breakdown, range status and provider-derived USD totals'). It distinguishes itself from sibling tools that focus on individual positions or actions by highlighting the cross-chain aggregate nature.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied through the word 'summary' and the compact nature of the output, suggesting use for a high-level overview. However, the description does not explicitly state when to use this tool over siblings like get_vfat_positions or get_vfat_position, nor does it mention any exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Finds a single position by NFT/token ID among the positions reported for an EVM admin address.
| Name | Required | Description | Default |
|---|---|---|---|
| token_id | Yes | NFT or position token ID | |
| admin_address | Yes | EVM admin/owner address used by vfat |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds the scoping constraint (positions reported for an EVM admin address) but does not disclose return format, error behavior, or pagination, which is acceptable given the simple read-only nature.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no redundant words. It efficiently conveys the tool's purpose and scope without waste.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple 2-parameter lookup with rich annotations (read-only, idempotent) and no output schema, the description is complete. It explains what the tool does, the key inputs, and the context (position for an EVM admin address), which is sufficient for an agent to select and invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema thoroughly documents both parameters. The description adds marginal context by linking token_id to the admin address (position found 'among the positions reported' for that address), but the schema already provides the essential semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool finds a single position by NFT/token ID for a given EVM admin address. It uses a specific verb ('Finds') and resource ('position'), and the scope ('among the positions reported for an EVM admin address') distinguishes it from siblings like get_vfat_positions (plural) and get_vfat_position_actions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied: use when you have a specific token ID and admin address to retrieve one position. However, it does not explicitly mention when not to use it or name alternative tools (e.g., get_vfat_positions for all positions), so it lacks explicit when/when-not guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Returns transaction-grouped lifecycle actions for one vfat/Sickle NFT position, including deposits, rebalances, cashflows, token deltas, dust, rewards and swaps.
| Name | Required | Description | Default |
|---|---|---|---|
| to | No | Optional inclusive ISO 8601 timestamp with timezone | |
| from | No | Optional inclusive ISO 8601 timestamp with timezone | |
| nft_id | Yes | NFT or position token ID | |
| chain_id | Yes | EVM chain ID | |
| nft_address | Yes | NFT position manager address | |
| sickle_address | Yes | Sickle account address | |
| include_raw_events | No | Include every raw provider event in each transaction group |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the read-only, idempotent, and non-destructive nature. The description adds useful detail about the content (lifecycle actions) but does not disclose additional behavioral aspects like pagination, ordering, or error cases. With annotations present, this is acceptable but not exceptional.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single clear sentence, front-loaded with the main action and resource, and includes a concise list of included action types. No fluff or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 7 parameters and no output schema, the description gives a solid summary of what the tool returns but does not specify the return structure (e.g., array vs object, grouping format) or any default behavior for time filters. It is adequate but not fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides 100% coverage with descriptions for all parameters. The tool description itself does not add any extra meaning beyond the schema, so baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns transaction-grouped lifecycle actions for a single vfat/Sickle position, listing specific action types (deposits, rebalances, etc.), which distinguishes it from sibling tools like get_vfat_position_value_history or get_vfat_portfolio_summary.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context that this tool is for a single NFT position's actions, implying use when detailed transaction history is needed. However, it does not explicitly mention alternatives or exclusion cases, so it falls short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Returns a chronological APR, ROI, PnL, realized PnL and balance time series for one vfat/Sickle NFT position.
| Name | Required | Description | Default |
|---|---|---|---|
| to | No | Optional inclusive ISO 8601 timestamp with timezone | |
| from | No | Optional inclusive ISO 8601 timestamp with timezone | |
| nft_id | Yes | NFT or position token ID | |
| chain_id | Yes | EVM chain ID | |
| nft_address | Yes | NFT position manager address | |
| sickle_address | Yes | Sickle account address |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint, covering the safety profile. The description adds value by specifying the exact metrics returned (APR, ROI, PnL, realized PnL, balance) and the chronological time series nature, which is useful context beyond the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence that front-loads the core purpose ('Returns...') and packs all essential information without unnecessary words. Every phrase contributes to understanding the tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a read-only tool with a full schema (6 params, all described) and strong annotations, the description sufficiently explains the tool's purpose and output content. It could mention the structure of the time series (e.g., array of objects) but is otherwise complete given the schema and annotations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description adds no additional parameter-level semantics beyond what the schema already provides, such as the role of from/to in filtering the time series. It relies entirely on the schema for parameter meaning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool 'Returns a chronological APR, ROI, PnL, realized PnL and balance time series for one vfat/Sickle NFT position.' This is a specific verb+resource with a clear scope (one position) and distinguishes it from siblings like portfolio summary (multi-position) and position value history (value-only).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage by specifying 'for one vfat/Sickle NFT position,' which suggests this is for a single position's performance over time. However, it does not explicitly mention alternatives or when not to use it, leaving the agent to infer distinctions from sibling names.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Returns all current vfat/Sickle positions reported for an EVM admin address, including provider metrics and underlying position fields.
| Name | Required | Description | Default |
|---|---|---|---|
| admin_address | Yes | EVM admin/owner address used by vfat |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint=false. The description adds useful context about the return content ('provider metrics and underlying position fields') and scope ('all current'), which goes beyond the annotations without contradicting them.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence that front-loads the main action and resource. It includes enough detail without wasting words, making it easy to parse and understand.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has a simple input (one parameter with full schema coverage), strong annotations, and no output schema. The description provides a clear scope and hints at the data returned, which is sufficient for a list-type read operation. It could be more explicit about the return format, but given the simplicity, it is adequately complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema fully describes the single parameter with a pattern and a clear description ('EVM admin/owner address used by vfat'). The description text repeats the notion of an EVM admin address but does not add new parameter semantics, so a baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Returns' and the specific resource 'all current vfat/Sickle positions reported for an EVM admin address'. It also elaborates on the content ('including provider metrics and underlying position fields'), which distinguishes it from sibling tools like get_vfat_position (singular) and portfolio summary.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implicitly communicates its use case by emphasizing 'all current positions', which differentiates it from more focused tools. However, it does not explicitly mention alternatives or when not to use it, so it stops short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Returns a chronological time series of position value, normalized underlying token balances and in-range status across NFT migrations and rebalances.
| Name | Required | Description | Default |
|---|---|---|---|
| to | No | Optional inclusive ISO 8601 timestamp with timezone | |
| from | No | Optional inclusive ISO 8601 timestamp with timezone | |
| nft_id | Yes | NFT or position token ID | |
| chain_id | Yes | EVM chain ID | |
| nft_address | Yes | NFT position manager address | |
| sickle_address | Yes | Sickle account address |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds behavioral context beyond the read-only/idempotent annotations by explaining the output is a chronological time series and spans migrations/rebalances. It does not contradict annotations, but it could disclose details like pagination or data availability limitations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that is clear and free of redundant information. Every phrase contributes to understanding the tool's output and scope.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description adequately explains the return values (position value, token balances, in-range status) and the historical scope across migrations. It could be more detailed about time range handling, but the schema covers parameters and the description is sufficient for a read-only tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the parameters are already fully documented. The description does not add significant meaning to parameters, but it aligns with the high coverage baseline without needing to compensate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns a chronological time series of position value, normalized token balances, and in-range status across migrations and rebalances. It uses a specific verb and resource, and the scope differentiates it from siblings like get_vfat_position (current state) and get_vfat_position_performance (performance metrics).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for historical value tracking across migrations/rebalances, but it does not explicitly state when to use this tool over alternatives or provide exclusions. It gives context but lacks direct comparison to sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v0.2.0export_vfat_position_csvget_vfat_portfolio_summaryget_vfat_positionget_vfat_position_actionsget_vfat_position_performanceget_vfat_position_value_historyget_vfat_positionsScored across 7 tools
Each tool targets a distinct aspect: portfolio summary aggregates across chains, positions list all, position finds one, actions provide lifecycle events, value history and performance provide different time series, and export handles CSV output. No two tools overlap in purpose.
All tools follow a consistent verb_vfat_noun pattern: get_ or export_ prefix, vfat_ domain marker, and a specific resource or metric. Singular/plural forms are used logically for list vs. single item.
Seven tools is well-scoped for a DeFi metrics server, covering summary, list, detail, history, performance, and export without excess. Each tool earns its place.
The toolset covers the full read-only analytics surface for vfat positions: portfolio-level summary, position listing, detail lookup, transaction actions, value history, performance metrics, and CSV export. No obvious gaps for the stated purpose.
Free read-only crypto whale-tracking & market-data MCP tools across 14 chains. No auth.
Official Aave MCP for V3 and V4 markets, positions, governance, and transaction preparation.
Pay-per-call DeFi and macro intel for AI agents. x402 USDC tools via streamable HTTP /api/mcp.
DefiLlama MCP — DeFi analytics from DefiLlama (free, no auth)