Which integrations are available for this server?

Enables interaction with NEAR smart contracts: read contract metadata, call view methods, decode transactions, and explore contract interfaces on mainnet or testnet.

How do I use near-contract?

1. Click on "Install 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., "@near-contract What's the balance of alice.near on wrap.near?" 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.

near-contract

by jim-agent

Overview Schema Related Servers Score Discussions

JavaScript

Remote

MCP Server: NEAR Smart Contract Interaction

An MCP (Model Context Protocol) server that allows Claude to read NEAR smart contract state, call view methods, decode transactions, and understand contract interfaces.

Features

Contract Metadata: Fetch code hash, storage usage, and detect implemented standards (NEP-141, NEP-171, etc.)
View Method Calls: Call any read-only method on any NEAR contract
Transaction Decoding: Decode and explain transaction actions, gas usage, and outcomes
State Reading: Read raw contract state with optional key prefix filtering
Interface Explanation: AI-friendly explanation of contract purpose and functions

Related MCP server: MCP Crypto Wallet EVM

Installation

npm install @near-mcp/contract-interaction

Or run directly:

npx @near-mcp/contract-interaction

Claude Desktop Configuration

Add to your Claude Desktop config (~/Library/Application Support/Claude/claude_desktop_config.json on macOS):

{
  "mcpServers": {
    "near-contract": {
      "command": "npx",
      "args": ["@near-mcp/contract-interaction"]
    }
  }
}

Available Tools

1. `get_contract_metadata`

Fetches contract metadata including code hash, storage usage, and detected methods/standards.

Input:

{
  "contract_id": "wrap.near",
  "network": "mainnet"
}

Output:

{
  "contract_id": "wrap.near",
  "network": "mainnet",
  "code_hash": "ABC123...",
  "storage_usage_bytes": 12345,
  "storage_usage_near": "0.12345 NEAR",
  "detected_methods": ["ft_transfer", "ft_balance_of", "ft_metadata"],
  "detected_standards": ["NEP-141 (Fungible Token Standard)"]
}

2. `call_view_method`

Calls a view (read-only) method on any NEAR smart contract.

Input:

{
  "contract_id": "wrap.near",
  "method_name": "ft_balance_of",
  "args": { "account_id": "example.near" },
  "network": "mainnet"
}

Output:

{
  "contract_id": "wrap.near",
  "method": "ft_balance_of",
  "args": { "account_id": "example.near" },
  "result": "1000000000000000000000000",
  "blockHeight": 123456789,
  "blockHash": "ABC...",
  "logs": []
}

3. `decode_transaction`

Decodes and explains a NEAR transaction, including all actions and their effects.

Input:

{
  "tx_hash": "ABC123...",
  "sender_id": "example.near",
  "network": "mainnet"
}

Output:

{
  "hash": "ABC123...",
  "signerId": "example.near",
  "receiverId": "wrap.near",
  "actions": [
    {
      "type": "FunctionCall",
      "description": "Calls method \"ft_transfer\" with 0.0100 NEAR attached",
      "details": {
        "method_name": "ft_transfer",
        "args_decoded": { "receiver_id": "bob.near", "amount": "1000000" },
        "gas": 30000000000000,
        "deposit": "1"
      }
    }
  ],
  "outcome": {
    "status": "Success",
    "gasUsed": "2.5432 TGas",
    "tokensBurned": "0.000254 NEAR"
  }
}

4. `get_contract_state`

Reads raw contract state entries, optionally filtered by key prefix.

Input:

{
  "contract_id": "example.near",
  "key_prefix": "",
  "network": "mainnet"
}

Output:

{
  "contract_id": "example.near",
  "network": "mainnet",
  "total_entries": 42,
  "state_entries": [
    {
      "key": "base64...",
      "keyDecoded": "STATE",
      "value": "base64...",
      "valueDecoded": "{\"owner\": \"alice.near\"}"
    }
  ],
  "truncated": false
}

5. `explain_contract_interface`

Analyzes a contract and provides a human-readable explanation of its purpose and main functions.

Input:

{
  "contract_id": "wrap.near",
  "network": "mainnet"
}

Output:

{
  "contract_id": "wrap.near",
  "network": "mainnet",
  "summary": "Wrapped NEAR (wNEAR) - A fungible token contract implementing the NEP-141 standard...",
  "detected_standards": ["NEP-141 (Fungible Token Standard)", "NEP-145 (Storage Management)"],
  "main_functions": {
    "token_operations": ["ft_transfer", "ft_transfer_call"],
    "queries": ["ft_balance_of", "ft_total_supply", "ft_metadata"],
    "storage": ["storage_deposit", "storage_withdraw"]
  },
  "token_info": {
    "name": "Wrapped NEAR",
    "symbol": "wNEAR",
    "decimals": 24
  },
  "example_usage": [
    "Check token balance: call_view_method(\"wrap.near\", \"ft_balance_of\", {\"account_id\": \"user.near\"})",
    "Get token info: call_view_method(\"wrap.near\", \"ft_metadata\", {})"
  ]
}

Supported Contract Standards

The server automatically detects contracts implementing:

NEP-141: Fungible Token Standard
NEP-171: Non-Fungible Token Standard
NEP-145: Storage Management
NEP-148: Fungible Token Metadata

Networks

Both mainnet and testnet are supported. Default is mainnet.

{ "network": "testnet" }

Development

# Install dependencies
npm install

# Build
npm run build

# Run locally
npm start

License

MIT

Available Tools

5 tools

call_view_methodA

Calls a view (read-only) method on any NEAR smart contract

ParametersJSON Schema

Name	Required	Description
`args`	No	Arguments to pass to the method (will be JSON encoded)
`network`	No	NEAR network to query (default: mainnet)
`contract_id`	Yes	The NEAR account ID of the contract
`method_name`	Yes	Name of the view method to call

TDQS

A3.7/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 clearly discloses the read-only nature, which is the key behavioral trait. However, it does not describe error behavior, return format, or any side effects (though view methods are non-mutating by definition).

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 wasted words. It conveys the core purpose immediately and includes the crucial read-only qualifier.

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?

The tool is simple and the schema covers all parameters, so the description is minimally adequate. However, with no output schema, the description omits what happens after the call (e.g., return value). For a generic view method, the return is unknown, but mentioning that it returns the contract's result would add useful context.

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%, so the baseline is 3. The description adds 'read-only' and 'any' but these are repetitive of the schema's field descriptions (e.g., 'view method'). It does not materially enrich parameter understanding beyond what the schema already provides.

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?

Description specifies a clear verb ('calls') and resource ('view method on any NEAR smart contract'), and explicitly marks it as read-only. This distinguishes it from sibling tools that handle metadata, state, transactions, or interface explanations.

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?

The description implies usage: call this when you need to invoke a view method on a NEAR contract. However, it provides no explicit when-not-to-use guidance or comparisons with sibling tools, so usage context is only implied.

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

decode_transactionA

Decodes and explains a NEAR transaction, including all actions and their effects

ParametersJSON Schema

Name	Required	Description
`network`	No	NEAR network to query (default: mainnet)
`tx_hash`	Yes	The transaction hash to decode
`sender_id`	Yes	The sender account ID (required for lookup)

TDQS

A3.5/5.0

Behavior2/5

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

With no annotations provided, the description carries the full burden of disclosing behavioral traits. While it states the output includes actions and effects, it does not explicitly confirm the operation is read-only, mention prerequisites, or describe error behavior. This leaves significant transparency gaps for an agent to safely invoke the tool.

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?

The description is a single concise and front-loaded sentence. It wastes no words, directly stating the verb and resource, and adds a brief scoping clause about actions and effects.

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?

The tool has a clear three-parameter schema but no output schema, so the description must compensate for missing return-value details. It partially does by mentioning actions and effects, but lacks information about output format, error handling, or network-specific behavior. The description is adequate but leaves gaps given the lack of structured output metadata.

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 input schema provides descriptions for all three parameters with 100% coverage, including default and enum values. The description adds no additional parameter semantics, so the baseline score of 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?

The description uses specific verbs 'decodes and explains' and a specific resource 'NEAR transaction', clearly distinguishing it from the contract-oriented sibling tools. Mentioning 'all actions and their effects' further clarifies the scope, making the purpose explicit and unambiguous.

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?

The description implies usage for decoding transactions, which is distinct from the contract-focused siblings, but it does not explicitly state when to use this tool versus alternatives. No exclusions or alternative tool references are provided, so guidance remains only implicit.

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

explain_contract_interfaceB

Analyzes a contract and provides a human-readable explanation of its purpose and main functions

ParametersJSON Schema

Name	Required	Description	Default
`network`	No	NEAR network to query (default: mainnet)
`contract_id`	Yes	The NEAR account ID of the contract

TDQS

B3.2/5.0

Behavior2/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 of disclosing behavior. It only says 'Analyzes' and 'provides explanation,' but does not disclose whether it is read-only, what data it accesses, potential costs, rate limits, or what form the explanation takes. This is a minimal transparency gap.

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?

The description is a single, clear sentence with no wasted words. It front-loads the main verb and outcome, and is appropriately sized for the tool's simplicity.

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?

For a tool with no annotations, no output schema, and only 2 parameters, the description should provide more context about what the explanation includes, whether it's a textual summary, and any caveats. The current description leaves the return format and depth of analysis unspecified, so it is incomplete for an agent deciding whether to use it.

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%, so the parameters are already documented in the schema. The description adds no additional meaning beyond the schema, which is acceptable per baseline 3. It does not explain how contract_id or network affect the explanation, but it also does not need to given high schema coverage.

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 uses a specific verb ('Analyzes') with a clear resource ('a contract') and outcome ('human-readable explanation of its purpose and main functions'). This clearly distinguishes it from sibling tools like get_contract_metadata or call_view_method, which have different purposes.

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 states what the tool does but provides no guidance on when to use it versus alternatives. It does not mention when to prefer this over get_contract_metadata or call_view_method, nor any exclusions or preconditions.

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

get_contract_metadataB

Fetches contract metadata including code hash, storage usage, and detected methods/standards

ParametersJSON Schema

Name	Required	Description	Default
`network`	No	NEAR network to query (default: mainnet)
`contract_id`	Yes	The NEAR account ID of the contract (e.g., "wrap.near")

TDQS

B3.3/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 burden of behavioral disclosure. It indicates the tool is a read operation by 'Fetches' and lists what will be retrieved, but it does not explicitly confirm non-mutating behavior, error conditions, or response structure. This is useful but not richly detailed.

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?

The description is a single focused sentence that efficiently states the tool's purpose and key outputs. There is no redundancy, fluff, or repetition of schema details, making it highly concise and easy to parse.

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?

Given the absence of an output schema or annotations, the description gives a reasonable summary of the return contents but lacks contextual guidance on selecting this tool over similar siblings. The moderate complexity of the tool calls for more usage context, so the description is adequate but incomplete.

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 input schema provides full descriptions for both parameters, including the network default, so the description adds no parameter-specific meaning. The summary of output contents (code hash, storage usage, etc.) is contextual rather than parameter-related, so the tool meets the schema-coverage baseline.

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 uses the verb 'Fetches' with a specific resource ('contract metadata') and enumerates concrete examples (code hash, storage usage, detected methods/standards), making the tool's purpose unambiguous. While it doesn't explicitly differentiate from sibling tools like get_contract_state, the metadata focus is distinct enough for basic selection.

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 offers no explicit guidance on when to use this tool versus alternatives such as get_contract_state or explain_contract_interface. No prerequisites, exclusions, or contextual triggers are mentioned, leaving the agent to infer usage solely from the tool name.

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

get_contract_stateA

Reads raw contract state entries, optionally filtered by key prefix

ParametersJSON Schema

Name	Required	Description
`network`	No	NEAR network to query (default: mainnet)
`key_prefix`	No	Base64-encoded key prefix to filter state (optional)
`contract_id`	Yes	The NEAR account ID of the contract

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 burden of behavioral disclosure. It discloses that the tool performs a read operation and that results are raw and optionally filtered by key prefix, but it does not mention return format, pagination, authentication, or any side effects. It adds some context but is not comprehensive.

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?

The description is a single concise sentence with no redundant words. It is front-loaded and every word contributes meaning, making it efficient and easy to read.

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 simple read tool with good schema coverage, the description is adequate but lacks return value information (no output schema) and does not explain what the raw state entries look like. It also does not specify prerequisites or limitations, leaving a few gaps in context.

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%, so the schema fully documents each parameter. The description adds minimal value by mentioning the optional key prefix filter, but this information is already present in the schema. It does not clarify network or contract_id beyond what the schema provides.

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 clearly states a specific action ('Reads raw contract state entries') and resource ('contract state entries'), and the optional key prefix filter adds specificity. It distinguishes itself from siblings like get_contract_metadata and call_view_method by focusing on raw state access.

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?

The description implies usage for retrieving raw state entries but provides no explicit guidance on when to choose this tool over alternatives, nor does it mention exclusions. It sets context but lacks direct 'when to use' instructions.

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

Install Server

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A3.7/5.0

Disambiguation4/5

Tools are mostly distinct: metadata, state, view methods, interface explanation, and transaction decoding each target a different aspect. The slight overlap between get_contract_metadata and explain_contract_interface (both reveal methods) is mitigated by metadata being raw and explain being high-level.

Naming Consistency5/5

All tool names follow a consistent verb_noun pattern in snake_case: get_contract_metadata, call_view_method, decode_transaction, get_contract_state, explain_contract_interface. No mixed conventions or ambiguous verbs.

Tool Count5/5

Five tools is well-scoped for a contract inspection/analysis server. Each tool serves a clear purpose without redundancy, and the count is within the ideal range for a focused MCP server.

Completeness4/5

The tool surface covers the core needs for understanding NEAR contracts: metadata, raw state, view methods, interface explanation, and transaction decoding. A minor gap is the lack of a tool to simulate or estimate gas for view calls, but the current set is coherent and functional.

Maintenance

ActivityInactive

ResponsivenessSyncing

Resources

GitHub Repository

Need Help?

Related Servers

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

🐴 Gulltoppr A
io.github.portdeveloper
Resolve any EVM contract ABI (even unverified, via decompilation), read, simulate, prepare txs.
Blockchain Web3 & Decentralized Tech Cryptocurrency
122
blockscout-mcp-server AOAuth
ai.smithery
Provide AI agents and automation tools with contextual access to blockchain data including balance…
Blockchain Web3 & Decentralized Tech Search
244
LMX Cloud LLM Inference A
io.lmxcloud
OpenAI-compatible LLM MCP (7 tools); chat via balance key or x402 USDC on Base
AI & Machine Learning Blockchain
92
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

Related MCP Servers

Veri5ight MCP Server
Blockchain Web3 & Decentralized Tech
5ajaki
A
license
B
quality
D
maintenance
Enables Claude to interact with Ethereum nodes, allowing users to check ENS token balances, view smart contract code, and decode transactions through natural language.
Updated 2 years ago (2025-01-31 04:17 UTC)
5
1
MIT
MCP Crypto Wallet EVM
Blockchain Web3 & Decentralized Tech Cryptocurrency
dcSpark
A
license
B
quality
D
maintenance
Provides Claude with access to Ethereum and EVM-compatible blockchain operations, enabling wallet management, transaction handling, contract interactions, and blockchain queries through natural language.
Updated a year ago (2025-03-26 03:12 UTC)
4
35
61
10
MIT
SolanaViz MCP Server
Blockchain Cryptocurrency Web3 & Decentralized Tech
FarseenSh
F
license
Not graded
quality
D
maintenance
Enables Claude to access, analyze, and visualize Solana blockchain data through natural language conversations.
Updated a year ago (2025-03-16 01:41 UTC)
18
MCP NEAR Wallet Server
Blockchain Web3 & Decentralized Tech Cryptocurrency
bigguybobby
A
license
Not graded
quality
D
maintenance
Enables Claude Desktop and MCP clients to interact with NEAR blockchain accounts for balance checks, account info, access keys, transaction status, and sending signed transactions.
Updated 7 months ago (2026-02-17 15:32 UTC)
MIT

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/jim-agent/mcp-near-contract'

If you have feedback or need assistance with the MCP directory API, please join our Discord server

MCP Server: NEAR Smart Contract Interaction

Features

Installation

Claude Desktop Configuration

Available Tools

1. get_contract_metadata

2. call_view_method

3. decode_transaction

4. get_contract_state

5. explain_contract_interface

Supported Contract Standards

Networks

Development

License

Available Tools

Maintenance

Resources

Looking for Admin?

Related MCP Connectors

Related MCP Servers

Latest Blog Posts

MCP directory API

1. `get_contract_metadata`

2. `call_view_method`

3. `decode_transaction`

4. `get_contract_state`

5. `explain_contract_interface`