EmblemAI MCP

EmblemAI MCP is a hosted remote server operated by EmblemVault that gives compatible AI clients documented access to wallet, blockchain, NFT, market, and research tools. The official product page and MCP documentation identify https://emblemvault.ai/api/mcp as the persistent HTTPS endpoint. The exact Smithery entry emblemai/emblem-mcp is marked as a remote deployment and explicitly says that its deployment connects directly to this EmblemAI endpoint. This mapping is therefore not inferred from the Smithery namespace; it is corroborated by the provider source. The operator presents EmblemAI as its own product on emblemvault.ai and also publishes the EmblemCompany/Agent-skills repository containing the local stdio bridge.

Data, networks, and tools

According to the provider, the service exposes more than 200 tools across Bitcoin, Solana, Ethereum, Base, BSC, Polygon, and Hedera; the current product page also describes workflows across eight supported blockchains. The documented surface may cover native coins and tokens, NFT and Ordinals data, Emblem Vault assets, wallet balances, historical activity, market and liquidity information, DeFi positions, research, and cross-chain workflows. The provider also describes market analysis, Polymarket functions, swap routing, and conditional positions such as limit, stop-loss, and take-profit orders. Actual availability depends on the network, account, liquidity, external providers, and the current tool catalog. Results are time-dependent data responses, not financial, investment, or transaction guarantees.

The data does not come from one authoritative official register. On-chain values originate from blockchains and connected RPC, indexing, market, or routing services. Market and research answers may include external sources and provider APIs. For consequential work, verify the source, block height, timestamp, network, asset identity, and freshness of every result. A model must not present unverified tool output as a final valuation, ownership proof, or certain execution outcome.

Authorization and privacy

The official documentation describes OAuth 2.0 with PKCE for interactive MCP sessions and API keys or bearer tokens for other client paths. According to the provider, OAuth is limited to vault:read access by default. An API key can provide broad read and write capabilities and must never be stored in catalog copy, source code, logs, prompts, or version control. Authentication authorizes only the account and role scope actually granted; it does not replace verification of the target wallet, network, or contract.

Requests and results pass through the remote service and may contain wallet, asset, market, or identity-related information. Do not submit private NFT metadata, seed phrases, private keys, credentials, or unnecessary personal data. Assess sharing, retention, logging, and model processing separately for the provider, Smithery, MCP client, and downstream model provider. The public product page does not prove that every external data source has identical privacy or licensing terms. The official repository identifies MIT for the published stdio bridge and documentation; the hosted SaaS service, integrated data sources, and their content may be subject to separate terms.

Transactions and security boundaries

The official MCP documentation describes a read-only tool surface by default. State-changing tools for transfers, sends, swaps, purchases, sales, minting, burning, key reveal, conditional orders, and other vault mutations appear only when the client sends the header x-mcp-transactions with the value enabled. The Smithery entry describes the same opt-in barrier and says that transaction tools require API-key authorization. This separation is an important control, but it is not a security guarantee: a compromised or overprivileged key may move assets. Block transaction tools by default, use least-privilege roles, confirm destination, network, asset, amount, fees, and slippage outside the language model, and never treat natural language as the sole approval. Review raw parameters and actual wallet authorization before execution. The server is independently catalog-worthy because its product identity, operator, official endpoint, provider documentation, repository, and license are traceable; it remains an external, changeable service without a guarantee of local data or execution.

FAQ

Is this an official service? According to the provider, EmblemAI is the EmblemVault-documented product; Smithery confirms the listing connects to its hosted endpoint, not that Smithery independently audits its security.

Can the service only read? The documentation says the default surface is read-only. Transaction tools require explicit opt-in and suitable API-key authorization.

Are wallet or market results definitive? No. They can depend on network latency, indexers, external sources, and tool updates and are not financial or execution guarantees.

An MCP-compatible client for hosted HTTP; OAuth 2.0 with PKCE or a separately managed EmblemAI API key or bearer token as documented by the provider.

Configure the remote server at https://emblemvault.ai/api/mcp in the MCP client and use the documented OAuth or API-key path. Do not enable transaction tools unless they are explicitly required and separately controlled.

According to the provider, OAuth 2.0 with PKCE supports interactive read sessions, while API keys or bearer tokens support additional client paths. Keys may grant write access and must never be shared or stored in catalog data.

Wallet, blockchain, NFT, market, and research queries; write tools for transfers, swaps, purchases, sales, minting, burning, and orders are hidden by default and require explicit opt-in.

Requests and results pass through the EmblemVault remote endpoint and may contain wallet, asset, market, or identity-related data. The client, Smithery, and model provider may apply separate logging, retention, and sharing rules.

Key compromise, prompt injection in external tool results, incorrect asset or network selection, stale indexed data, and unintended transactions. Block transaction tools by default and approve every execution outside the model.