Base Intel MCP

Name: Base Intel MCP
Author: datakoot

Server Details

Read-only on-chain intelligence for AI agents on Base: balances, tokens, gas, tx status.

If you are the author of this connector, you can claim ownership by verifying the domain or GitHub account it belongs to. Claimed connector authors can inspect health checks, view analytics, and manage their listing.

Status: Healthy
Uptime: 100.0% over 41 days
Last Tested: 2026-10-17 11:43
Transport: Streamable HTTP · MCP 2025-06-18
URL
Repository: datakoot/base-intel-mcp
GitHub Stars: 0
Server Listing: Base Intel MCP

TDQS

A4.2/5.0

Scored 2026-10-15 06:40 across 5 tools

Disambiguation5/5

Each tool targets a distinct resource and question: address overview (address_report), gas price (gas_now), token holdings (token_balance), token metadata (token_info), and transaction status (tx_status). There is no overlap in purpose, so an agent can select unambiguously.

Naming Consistency5/5

All five tools follow a consistent snake_case, resource_or_action naming pattern (address_report, gas_now, token_balance, token_info, tx_status). The convention is uniform and predictable throughout.

Tool Count5/5

Five tools is well-scoped for a read-only Base network intelligence server. Each tool earns its place and covers a meaningful, non-redundant query without bloat.

Completeness4/5

The surface covers the core read paths: address sanity-check, gas, token balance, token metadata, and tx confirmation. Minor gaps exist (e.g. no block info or token transfer history), but the essential agent workflows are supported without dead ends.

Available Tools

5 tools

address_reportAddress ReportA

Read-onlyIdempotent

Inspect

One-call snapshot of any Base address: ETH balance, USDC balance, transaction count, and whether it is a smart contract or a regular wallet. Use it to sanity-check a counterparty or a payment address before sending funds. Input: a 0x address.

ParametersJSON Schema

Name	Required	Description	Default
`address`	Yes	0x address on Base

Output Schema

ParametersJSON Schema

Name	Required	Description
`address`	No
`network`	No
`tx_count`	No
`provenance`	No	Where this answer came from. served_at is when Datakoot answered (UTC); upstream lists the official sources consulted. Datakoot may serve a briefly cached copy, so the source's own observation can be older than served_at.
`eth_balance`	No
`is_contract`	No
`usdc_balance`	No

TDQS

A4.1/5.0

Behavior4/5

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

Annotations already declare readOnly, idempotent, non-destructive, and open-world behavior, so the safety profile is covered. The description adds the operational shape of the tool (single call, fixed field set, Base-only scope), which is genuinely useful beyond the annotations, though it says nothing about rate limits, caching, or freshness of the data.

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 what it returns and followed by the use case and input. No filler or redundant phrasing.

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 an output schema present, return values need not be explained, and annotations carry the safety profile. The description covers scope (Base), trigger context, and input type, leaving nothing an agent needs in order to call it correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The single parameter is already fully documented in the schema ('0x address on Base', 100% coverage). 'Input: a 0x address' restates the schema without adding format, checksum, or validation detail, so baseline 3 applies.

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 ('snapshot') and resource ('any Base address') and enumerates the exact contents returned: ETH balance, USDC balance, tx count, and contract-vs-wallet classification. It does not explicitly differentiate itself from siblings like token_balance, which plausibly overlaps on balance lookups, so it falls just short of a 5.

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?

Gives a clear when-to-use context: sanity-check a counterparty or payment address before sending funds. It stops short of naming alternatives or stating when not to use it (e.g. for token-specific queries, use token_balance).

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

gas_nowGas NowA

Read-onlyIdempotent

Inspect

Current gas price on the Base network (Coinbase's Ethereum L2), in gwei and wei, read live from a Base RPC node. Use before sending a Base transaction or estimating its cost. Takes no input.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

Output Schema

ParametersJSON Schema

Name	Required	Description
`network`	No
`provenance`	No	Where this answer came from. served_at is when Datakoot answered (UTC); upstream lists the official sources consulted. Datakoot may serve a briefly cached copy, so the source's own observation can be older than served_at.
`gas_price_wei`	No
`gas_price_gwei`	No

TDQS

A4.5/5.0

Behavior4/5

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

Annotations already declare readOnly, idempotent, non-destructive and open-world, so the safety profile is covered. The description adds genuinely new behavioral context: the value is read live from a Base RPC node and returned in two denominations, which tells the agent about freshness and output shape 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.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Three short sentences, front-loaded with the resource and network, then use case, then arity. Every sentence earns its place with no filler.

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 an output schema present, the description need not explain return values, and with zero parameters and rich annotations there is little else to cover. Purpose, timing, source, and arity are all stated, so nothing an agent needs to invoke it 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?

Zero parameters, so the baseline is 4. The description confirms this explicitly ('Takes no input'), matching the empty input schema, and adds no misleading parameter hints.

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 resource (current gas price), the exact network (Base, with a clarifying gloss), and the units returned (gwei and wei). This is unmistakably distinct from the sibling tools (address_report, token_info, token_balance, tx_status), none of which report gas.

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?

Gives a clear triggering context: 'Use before sending a Base transaction or estimating its cost.' No exclusions or alternatives are named, but no sibling overlaps this capability, so the guidance is effectively complete.

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

token_balanceToken BalanceA

Read-onlyIdempotent

Inspect

How much of an ERC-20 token a wallet holds on Base, returned both human-formatted (using the token's decimals) and raw. Pass the token contract address and the holder address, both 0x + 40 hex. Example: USDC 0x833589fcd6edb6e08f4c7c32d4f71b54bda02913.

ParametersJSON Schema

Name	Required	Description	Default
`token`	Yes	ERC-20 contract address on Base: 0x followed by 40 hex characters.
`address`	Yes	Wallet address whose balance to read: 0x followed by 40 hex characters.

Output Schema

ParametersJSON Schema

Name	Required	Description
`token`	No
`holder`	No
`symbol`	No
`balance`	No
`network`	No
`decimals`	No
`provenance`	No	Where this answer came from. served_at is when Datakoot answered (UTC); upstream lists the official sources consulted. Datakoot may serve a briefly cached copy, so the source's own observation can be older than served_at.
`balance_raw`	No

TDQS

A3.7/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, openWorld), so the bar is lower. The description still adds real value beyond them: it discloses that the result comes back in two forms (decimals-adjusted and raw) and pins the chain to Base, plus the address literal format.

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?

Two sentences, front-loaded with the core capability and the output shape, followed by an actionable example. Slight redundancy: the '0x + 40 hex' constraint is repeated verbatim from the two schema parameter descriptions.

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 simple two-address read with an output schema, the description gives chain, address format, result formatting, and a valid example — enough to invoke correctly. Only minor gaps remain (e.g., behavior on a non-ERC-20 or wrong-chain address), which edge cases rarely determine selection.

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%, so both parameters are already fully documented in the schema; baseline is 3. The description restates the 0x + 40 hex format and adds a worked USDC example, which is marginally useful but largely duplicates the schema text.

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 concrete operation (read how much of a specific ERC-20 token a specific wallet holds) with an explicit scope (Base, fixed token+holder pair). This is intrinsically distinguishable from token_info (token metadata) and address_report (broader wallet view), so an agent can route correctly without opening a schema.

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?

The description explains how to fill the parameters but never says when to choose this tool over address_report or token_info, nor when it is not appropriate. No preconditions, no exclusions, no named alternatives are given.

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

token_infoToken InfoA

Read-onlyIdempotent

Inspect

ERC-20 token metadata on Base, read on-chain: name, symbol, decimals, and total supply, plus whether the address really behaves like an ERC-20. Use it to verify a token contract before trusting or displaying it. Input: the token contract address (0x + 40 hex).

ParametersJSON Schema

Name	Required	Description	Default
`token`	Yes	ERC-20 contract address on Base: 0x followed by 40 hex characters.

Output Schema

ParametersJSON Schema

Name	Required	Description
`name`	No
`token`	No
`symbol`	No
`network`	No
`decimals`	No
`is_erc20`	No
`provenance`	No	Where this answer came from. served_at is when Datakoot answered (UTC); upstream lists the official sources consulted. Datakoot may serve a briefly cached copy, so the source's own observation can be older than served_at.
`total_supply`	No

TDQS

A4.1/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, openWorld), so the description only needs to add context. It does: it discloses that the read happens on-chain and that the result includes a behavioral ERC-20 conformance check, which is a real semantic beyond the annotations. It does not describe behavior on invalid/non-ERC-20 addresses, but the bar is lower given annotation coverage.

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?

Three tight sentences, front-loaded with what is returned before the usage note. The trailing 'Input: the token contract address (0x + 40 hex)' duplicates the schema's parameter description, which is the one mildly wasteful element, keeping it from a 5.

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?

An output schema exists, so return values need no explanation, and the description still signals the conformance-check output. Purpose, when-to-use, and input format are all covered; the only gap is explicit sibling routing (e.g. token_balance for amounts), which is minor for a one-parameter read tool.

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 100% with a single required parameter, so the schema already documents the address format. The description restates the same 0x + 40 hex format without adding syntax, network caveats, or validation detail beyond the schema. Baseline 3 is appropriate.

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 (read), resource (ERC-20 token metadata), chain (Base), and enumerates the exact fields returned (name, symbol, decimals, total supply) plus a contract-validity signal. This clearly separates it from siblings like token_balance (balance only) and address_report, so an agent can pick it without opening the 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?

Explicitly says when to use it: 'verify a token contract before trusting or displaying it.' That is a clear trigger condition. It does not, however, name an alternative tool or state when-not to use it (e.g. vs. token_balance for holdings), so it stops short of full routing guidance.

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

tx_statusTx StatusA

Read-onlyIdempotent

Inspect

Look up a Base transaction by hash and report whether it is pending, succeeded, or failed, with from, to, value, block number, and gas used. Use it to confirm a payment or contract call landed. Input: the transaction hash (0x + 64 hex; the 0x is optional).

ParametersJSON Schema

Name	Required	Description	Default
`hash`	Yes	Transaction hash, 0x followed by 64 hex characters (the 0x prefix is optional).

Output Schema

ParametersJSON Schema

Name	Required	Description
`to`	No
`from`	No
`hash`	No
`found`	No
`status`	No
`network`	No
`gas_used`	No
`value_eth`	No
`provenance`	No	Where this answer came from. served_at is when Datakoot answered (UTC); upstream lists the official sources consulted. Datakoot may serve a briefly cached copy, so the source's own observation can be older than served_at.
`block_number`	No

TDQS

A4.3/5.0

Behavior4/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. The description adds the possible statuses (pending, succeeded, failed) and returned fields, which enriches understanding of what the tool reports without contradicting annotations.

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: the first front-loads the core purpose and returned data, the second gives usage and input format. Every sentence earns its place with no waste.

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?

For a simple single-parameter read tool with an output schema and full annotations, the description covers purpose, usage context, and input format adequately. Nothing essential is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, and the schema already fully documents the hash parameter including format and optional 0x prefix. The description repeats this information verbatim, adding no new semantic value.

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 ('look up') and resource ('Base transaction by hash') and enumerates the reported fields and statuses. It is clearly distinct from siblings like address_report, token_info, token_balance, and gas_now, which cover addresses, tokens, balances, and gas—not transaction status.

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 gives a clear use case: 'Use it to confirm a payment or contract call landed.' This provides explicit context for when to call it, though no exclusions or alternatives are mentioned.

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.

5 tool updatesOct 8, 2026

Changedaddress_report1 field changed

addedOutput schema / properties / provenance

Added value: +{
+  "description": "Where this answer came from. served_at is when Datakoot answered (UTC); upstream lists the official sources consulted. Datakoot may serve a briefly cached copy, so the source's own observation can be older than served_at.",
+  "properties": {
+    "may_be_cached": {
+      "type": "boolean"
+    },
+    "publisher": {
+      "type": "string"
+    },
+    "served_at": {
+      "format": "date-time",
+      "type": "string"
+    },
+    "upstream": {
+      "items": {
+        "type": "string"
+      },
+      "type": "array"
+    }
+  },
+  "type": "object"
+}

Changedgas_now1 field changed

addedOutput schema / properties / provenance

Added value: +{
+  "description": "Where this answer came from. served_at is when Datakoot answered (UTC); upstream lists the official sources consulted. Datakoot may serve a briefly cached copy, so the source's own observation can be older than served_at.",
+  "properties": {
+    "may_be_cached": {
+      "type": "boolean"
+    },
+    "publisher": {
+      "type": "string"
+    },
+    "served_at": {
+      "format": "date-time",
+      "type": "string"
+    },
+    "upstream": {
+      "items": {
+        "type": "string"
+      },
+      "type": "array"
+    }
+  },
+  "type": "object"
+}

Changedtoken_balance1 field changed

addedOutput schema / properties / provenance

Added value: +{
+  "description": "Where this answer came from. served_at is when Datakoot answered (UTC); upstream lists the official sources consulted. Datakoot may serve a briefly cached copy, so the source's own observation can be older than served_at.",
+  "properties": {
+    "may_be_cached": {
+      "type": "boolean"
+    },
+    "publisher": {
+      "type": "string"
+    },
+    "served_at": {
+      "format": "date-time",
+      "type": "string"
+    },
+    "upstream": {
+      "items": {
+        "type": "string"
+      },
+      "type": "array"
+    }
+  },
+  "type": "object"
+}

Changedtoken_info1 field changed

addedOutput schema / properties / provenance

Added value: +{
+  "description": "Where this answer came from. served_at is when Datakoot answered (UTC); upstream lists the official sources consulted. Datakoot may serve a briefly cached copy, so the source's own observation can be older than served_at.",
+  "properties": {
+    "may_be_cached": {
+      "type": "boolean"
+    },
+    "publisher": {
+      "type": "string"
+    },
+    "served_at": {
+      "format": "date-time",
+      "type": "string"
+    },
+    "upstream": {
+      "items": {
+        "type": "string"
+      },
+      "type": "array"
+    }
+  },
+  "type": "object"
+}

Changedtx_status1 field changed

addedOutput schema / properties / provenance

Added value: +{
+  "description": "Where this answer came from. served_at is when Datakoot answered (UTC); upstream lists the official sources consulted. Datakoot may serve a briefly cached copy, so the source's own observation can be older than served_at.",
+  "properties": {
+    "may_be_cached": {
+      "type": "boolean"
+    },
+    "publisher": {
+      "type": "string"
+    },
+    "served_at": {
+      "format": "date-time",
+      "type": "string"
+    },
+    "upstream": {
+      "items": {
+        "type": "string"
+      },
+      "type": "array"
+    }
+  },
+  "type": "object"
+}

5 tool updatesOct 3, 2026

Changedaddress_report1 field changed

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "additionalProperties": true,
+  "properties": {
+    "address": {},
+    "eth_balance": {},
+    "is_contract": {},
+    "network": {},
+    "tx_count": {},
+    "usdc_balance": {}
+  },
+  "type": "object"
+}

Changedgas_now1 field changed

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "additionalProperties": true,
+  "properties": {
+    "gas_price_gwei": {},
+    "gas_price_wei": {},
+    "network": {}
+  },
+  "type": "object"
+}

Changedtoken_balance1 field changed

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "additionalProperties": true,
+  "properties": {
+    "balance": {},
+    "balance_raw": {},
+    "decimals": {},
+    "holder": {},
+    "network": {},
+    "symbol": {},
+    "token": {}
+  },
+  "type": "object"
+}

Changedtoken_info1 field changed

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "additionalProperties": true,
+  "properties": {
+    "decimals": {},
+    "is_erc20": {},
+    "name": {},
+    "network": {},
+    "symbol": {},
+    "token": {},
+    "total_supply": {}
+  },
+  "type": "object"
+}

Changedtx_status2 fields changed

changedInput schema / properties / hash / description

Previous value: -"Transaction hash on Base: 0x followed by 64 hex characters."New value: +"Transaction hash, 0x followed by 64 hex characters (the 0x prefix is optional)."

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "additionalProperties": true,
+  "properties": {
+    "block_number": {},
+    "found": {},
+    "from": {},
+    "gas_used": {},
+    "hash": {},
+    "network": {},
+    "status": {},
+    "to": {},
+    "value_eth": {}
+  },
+  "type": "object"
+}

5 tool updatesSep 6, 2026
- First observedaddress_report
- First observedgas_now
- First observedtoken_balance
- First observedtoken_info
- First observedtx_status

Related MCP Connectors

Base Intel MCP A
io.github.selflabbs
Read-only on-chain intelligence for AI agents on Base: balances, tokens, gas, tx status.
Blockchain Cryptocurrency Web3 & Decentralized Tech
2
santyvv-data — market & on-chain data A
com.santyvv
Market and on-chain crypto data for AI agents. Pay per call in USDC on Base (x402).
Cryptocurrency Blockchain
81
47620 Base + Polygon Data API A
xyz.47620
Pay-per-call Base and Polygon onchain data over x402 for AI agents.
Blockchain Cryptocurrency Web3 & Decentralized Tech
181
CryptoPulse Data API A
ai.saascloud
Pay-per-call crypto market intelligence for AI agents. USDC on Base via x402.
Cryptocurrency Web3 & Decentralized Tech Finance
111

Related MCP Servers

evmcp
Blockchain Web3 & Decentralized Tech
siriuslattice
A
license
Not graded
quality
D
maintenance
Enables AI assistants to query on-chain data across EVM chains like Base, Optimism, Avalanche, Celo, and Arbitrum, including balances, transactions, gas, and smart contract interactions.
Updated 6 months ago (2026-04-08 23:35 UTC)
30 npm
MIT
chain-data
Cryptocurrency Blockchain
Baneado98
A
license
A
quality
C
maintenance
Enables AI agents to fetch live multi-chain portfolio, token info, gas prices, and token prices across Ethereum, Base, Polygon, Arbitrum, and Optimism with a single call. No API key required.
Updated 4 months ago (2026-06-22 16:39 UTC)
4
MIT
base-wallet-toolkit-mcp
Blockchain Cryptocurrency Web3 & Decentralized Tech
lordbasilaiassistant-sudo
A
license
A
quality
C
maintenance
Enables AI agents to interact with Base chain wallets, providing tools for checking balances, estimating gas, inspecting tokens, verifying allowances, and more.
Updated a month ago (2026-09-13 22:24 UTC)
7
23 npm
1
MIT
Base Pulse
Blockchain Cryptocurrency Security
Timothymycompc
A
license
Not graded
quality
B
maintenance
Enables AI agents to run honeypot and owner-power safety checks on Base tokens and to read wallet ETH and USDC balances, with every answer sourced from real chain data and paid per call in USDC via x402.
Updated 2 days ago (2026-10-15 22:12 UTC)
MIT

Try in Browser

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

Glama MCP Gateway

Add one secure layer between your agents and this server.

Server Details

Available Tools

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Tool Schema Changelog

Related MCP Connectors

Related MCP Servers

Glama MCP Gateway

Resources