NEAR Contract Deployer MCP Server
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| deploy_contractB | Deploy a WebAssembly (WASM) smart contract to a NEAR account. Requires the deployer account to have sufficient balance for storage costs. |
| initialize_contractA | Call an initialization method on a deployed contract. Most contracts require this after deployment. |
| upgrade_contractA | Upgrade an existing contract with new WASM code. The contract must be owned by the signer. |
| get_deployment_statusA | Check if a NEAR account has a smart contract deployed and get deployment details. |
| estimate_deployment_costA | Calculate the storage cost for deploying a WASM contract before actually deploying. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 5 tools
Each tool targets a distinct phase in the contract lifecycle: deploy creates, initialize configures, upgrade replaces, status checks, and cost estimates. There is no overlap or ambiguity between them.
All tool names follow a consistent verb_noun pattern (deploy_contract, initialize_contract, upgrade_contract, get_deployment_status, estimate_deployment_cost). The pattern is uniform and predictable.
With 5 tools, the server is well-scoped for its purpose of managing NEAR contract deployments. Each tool is necessary and there is no redundancy or bloat.
The server covers the full deployment lifecycle: estimation, deployment, initialization, upgrading, and status checking. There are no obvious gaps for its stated purpose, as contract interaction beyond deployment is out of scope.