What can you do with this server?

This server gives AI coding assistants real-time access to MetaMask Embedded Wallets documentation, SDK references, integration examples, and community support resources to accelerate integration development. * search_docs — Search documentation and example projects by query, with optional filters for platform (React, Vue, Flutter, Android, iOS, etc.), blockchain family (EVM, Solana, other), and category (quick-start, custom-auth, blockchain, feature, playground). * get_doc — Fetch the full content of any documentation page from docs.metamask.io, using Algolia, llms.txt, and GitHub raw MDX as fallbacks. * get_example — Retrieve complete source code of a Web3Auth integration example from GitHub, filterable by name, platform, blockchain family, category, or authentication method (e.g., Auth0, Firebase, Google). * get_sdk_reference — Fetch SDK source code (type definitions, interfaces, React hooks, Vue composables, error types, main class implementations) directly from open-source Web3Auth SDK repositories for verifying exact types, signatures, and available hooks. * search_community — Search or fetch posts from the MetaMask Builder Hub community forum for troubleshooting, workarounds, and known issues. Supports keyword searches and fetching full discussion threads by topic ID.

Which integrations are available for this server?

Provides access to documentation, code examples, and SDK reference for integrating MetaMask Embedded Wallets into Flutter applications. Provides access to documentation, code examples, and SDK reference for integrating MetaMask Embedded Wallets into Next.js applications. Provides access to documentation, code examples, and SDK reference for integrating MetaMask Embedded Wallets into React applications. Provides access to documentation, code examples, and SDK reference for integrating MetaMask Embedded Wallets using the Wagmi library for Ethereum.

de en es ja ko ru zh

MetaMask Embedded Wallets MCP

by Web3Auth

Overview Schema Related Servers Score Discussions

TypeScript

Remote

MetaMask Embedded Wallets MCP Server

Build MetaMask Embedded Wallets integrations faster by giving your AI coding assistant live access to the documentation and deep knowledge of the SDK.

There are two things to set up:

Skill — Teaches your AI assistant how to think about the SDK: architecture, framework quirks, key derivation rules, and common mistakes. No code in the skill; the MCP provides that.
MCP server — Gives your AI assistant real-time access to search docs, fetch examples, and look up SDK types.

MCP Tools

Tool	What it does
`search_docs`	Search documentation and example projects
`get_doc`	Fetch the full content of any doc page
`get_example`	Fetch complete source code of an integration example
`get_sdk_reference`	Fetch SDK types and hooks from the open-source repos
`search_community`	Search the MetaMask Builder Hub for real user issues

Related MCP server: Privy MCP Server

Skill

The skill teaches your AI assistant the mental model for MetaMask Embedded Wallets. It includes SDK selection logic, key derivation rules, authentication concepts, platform quirks, and common mistakes that aren't obvious from the docs alone.

Tip: For the best experience, use the MCP server alongside the skill so that your LLM can fetch live docs and examples rather than relying on static text.

Universal install (works with 40+ agents)

npx skills add web3auth/skill

The skills CLI by Vercel detects your active AI agent and installs to the right directory automatically — Cursor, Claude Code, Copilot, Kiro, Cline, Codex, Antigravity, and 40+ more.

To install for target a specific agent:

npx skills add web3auth/skill -a cursor     # Cursor only
npx skills add web3auth/skill -a claude-code # Claude Code only

MCP Server Setup

Cursor

The fastest way is one click:

Add MetaMask Embedded Wallets MCP to Cursor

Or install via Cursor Marketplace — search "MetaMask Embedded Wallets".

Or add it manually. Open Cursor Settings → Tools & Integrations → MCP and add:

{
  "mcpServers": {
    "web3auth": {
      "url": "https://mcp.web3auth.io"
    }
  }
}

VS Code (GitHub Copilot)

Install from the Visual Studio Marketplace — search "MetaMask Embedded Wallets", or:

code --install-extension Web3Auth.metamask-embedded-wallets

Or use the one-click install URL:

vscode:mcp/install?{"name":"web3auth","url":"https://mcp.web3auth.io"}

Or add manually to your workspace .vscode/mcp.json:

{
  "servers": {
    "web3auth": {
      "type": "http",
      "url": "https://mcp.web3auth.io"
    }
  }
}

JetBrains (IntelliJ, PyCharm, WebStorm, Android Studio)

Install from the JetBrains Marketplace — search "MetaMask Embedded Wallets".

Or add manually in Settings → Tools → AI Assistant → Model Context Protocol (MCP):

{
  "mcpServers": {
    "web3auth": {
      "url": "https://mcp.web3auth.io",
      "transport": "http"
    }
  }
}

Claude Code CLI

claude mcp add --transport http web3auth https://mcp.web3auth.io

Or add manually to your project's claude.json:

{
  "mcpServers": {
    "web3auth": {
      "url": "https://mcp.web3auth.io"
    }
  }
}

Claude Desktop

Open your Claude Desktop configuration file:

macOS: ~/Library/Application Support/Claude/claude_desktop_config.json
Windows: %APPDATA%\Claude\claude_desktop_config.json

Add the server to the mcpServers section:

{
  "mcpServers": {
    "web3auth": {
      "url": "https://mcp.web3auth.io"
    }
  }
}

Restart Claude Desktop and ask: "Search MetaMask Embedded Wallets docs for React quick start" to verify the connection.

ChatGPT Desktop

Open ChatGPT Desktop → Settings → Connections and add a new MCP server:

Name: web3auth
URL: https://mcp.web3auth.io

Windsurf

Open Windsurf Settings → MCP and add:

{
  "mcpServers": {
    "web3auth": {
      "serverUrl": "https://mcp.web3auth.io"
    }
  }
}

Or edit ~/.codeium/windsurf/mcp_config.json directly.

Kiro (AWS)

Add to your project's .kiro/settings/mcp.json:

{
  "mcpServers": {
    "web3auth": {
      "url": "https://mcp.web3auth.io"
    }
  }
}

Warp Terminal

In Warp, open Settings → AI → MCP Servers and click Add Server:

Name: web3auth
URL: https://mcp.web3auth.io

Or use Warp's one-click MCP install if available in your version.

Cline (VS Code)

Add to your Cline MCP settings (Ctrl+Shift+P → "Cline: Open MCP Settings"):

{
  "mcpServers": {
    "web3auth": {
      "url": "https://mcp.web3auth.io",
      "transport": "http"
    }
  }
}

Continue.dev

Add to your Continue config.json (open with Ctrl+Shift+P → "Continue: Open config.json"):

{
  "mcpServers": [
    {
      "name": "web3auth",
      "url": "https://mcp.web3auth.io"
    }
  ]
}

Zed

Add to your Zed settings.json (Cmd+, to open):

{
  "context_servers": {
    "web3auth": {
      "command": {
        "path": "npx",
        "args": ["-y", "mcp-remote", "https://mcp.web3auth.io"]
      }
    }
  }
}

Or install via Zed Extensions — search "MetaMask Embedded Wallets".

Antigravity

Open your MCP configuration file:

macOS/Linux: ~/.config/antigravity/mcp.json
Windows: %APPDATA%\antigravity\mcp.json

Add the server to the mcpServers section:

{
  "mcpServers": {
    "web3auth": {
      "url": "https://mcp.web3auth.io"
    }
  }
}

Antigravity hot-reloads MCP config changes — no restart required.

Xcode (via GitHub Copilot)

Xcode 26.3+ supports MCP via GitHub Copilot. Add the server to your Copilot MCP config or use the VS Code extension setup above (Copilot MCP registry is shared).

Alternatively, configure Xcode's agentic tools to point at https://mcp.web3auth.io directly via Settings → Copilot → MCP Servers.

Eclipse (via GitHub Copilot)

Eclipse with GitHub Copilot supports MCP. Add via Eclipse → Preferences → GitHub Copilot → MCP Servers → Add Server:

Name: web3auth
URL: https://mcp.web3auth.io

Neovim (avante.nvim)

In your Lua config, add via mcphub.nvim:

require("mcphub").setup({
  servers = {
    web3auth = {
      url = "https://mcp.web3auth.io",
      transport = "streamable-http",
    },
  },
})

Or using mcp-remote for compatibility:

require("avante").setup({
  mcp = {
    servers = {
      web3auth = {
        command = "npx",
        args = { "-y", "mcp-remote", "https://mcp.web3auth.io" },
      },
    },
  },
})

Neovim (codecompanion.nvim)

require("codecompanion").setup({
  extensions = {
    mcp = {
      servers = {
        web3auth = {
          command = "npx",
          args = { "-y", "mcp-remote", "https://mcp.web3auth.io" },
        },
      },
    },
  },
})

Amp (Sourcegraph)

Add to your Amp MCP configuration:

{
  "mcpServers": {
    "web3auth": {
      "url": "https://mcp.web3auth.io"
    }
  }
}

Goose

Add to ~/.config/goose/config.yaml:

extensions:
  - name: web3auth
    type: http
    url: https://mcp.web3auth.io

5ire

In 5ire Settings → MCP Servers → Add:

Name: web3auth
URL: https://mcp.web3auth.io

Aider

Aider supports MCP via the LiteLLM bridge. Add to your Aider config:

mcp_servers:
  web3auth:
    command: npx
    args: ["-y", "mcp-remote", "https://mcp.web3auth.io"]

Codex CLI

For Codex CLI or any stdio-only agent, use mcp-remote to bridge the HTTP endpoint:

npm install -g mcp-remote

Then add to ~/.codex/config.toml:

[mcp_servers.web3auth]
command = "npx"
args = ["-y", "mcp-remote", "https://mcp.web3auth.io"]

Or add to your agent's JSON config:

{
  "mcpServers": {
    "web3auth": {
      "command": "npx",
      "args": ["-y", "mcp-remote", "https://mcp.web3auth.io"]
    }
  }
}

Static docs (llms.txt)

If your AI tool doesn't support MCP yet, use the static documentation file instead:

https://docs.metamask.io/llms-full.txt

For tools that support the llms.txt spec and can index docs automatically:

https://docs.metamask.io/llms.txt

Warning: The static file is a snapshot and may not include the latest updates. Use the MCP server when possible for always-current docs.

Start building

Once the skill and MCP are set up, ask your AI assistant directly. Good starting prompts:

"Add MetaMask Embedded Wallets to my React app with Google login."
"Set up social login wallets in my Next.js app using Wagmi."
"Integrate embedded wallets in my Flutter app."
"Why are my users getting different wallet addresses after I changed the login method?"

Tip: Use planning mode (where available) for your initial prompt. Review the plan before generating code — this catches architecture mistakes early and avoids config errors that would change wallet addresses in production.

Distribution

This repo ships artifacts for every major developer platform:

Platform	Type	Location
Cursor Marketplace	Plugin	`.cursor-plugin/` + `mcp.json`
VS Code Marketplace	Extension	`plugins/vscode/`
JetBrains Marketplace	Plugin	`plugins/jetbrains/`
Zed Extensions	Extension	`plugins/zed/`
Claude Agent SDK	Plugin	`plugins/claude/`
Raycast Store	Extension	`plugins/raycast/`
ChatGPT GPT Store	Custom GPT	`openai/`
Official MCP Registry	`server.json`	`server.json`
Glama	`glama.json`	`glama.json`
Smithery	Server card	`app/.well-known/mcp/server-card.json/route.ts`
Vercel skills.sh	Skill	`Web3Auth/skill`
agentskill.sh	Skill	`Web3Auth/skill`

Environment Variables

Variable	Required	Description
`GITHUB_TOKEN`	Yes (hosted) / recommended (local)	GitHub personal access token. Required on the Vercel deployment (`mcp.web3auth.io`) — `get_example` and `get_sdk_reference` call the GitHub API heavily; without a token the shared IP hits the 60 req/hr unauthenticated limit quickly. Optional for local stdio use.
`DISCOURSE_API_KEY`	No	Discourse API key for `search_community` (optional; public search works without it)
`DISCOURSE_API_USERNAME`	No	Discourse API username when using `DISCOURSE_API_KEY`

Development

npm install
npm run build
npm test           # Handler smoke tests (mocked fetch)
npm start          # Run via stdio
npm run dev        # Watch mode

Updating Content

What changed	Where to update
SDK architecture, platform quirks, key derivation, workflow	Web3Auth/skill (`SKILL.md`)
New example repository or scan root (e.g. new platform)	`src/content/example-catalog.ts`
New SDK repository or discovery rules (e.g. new platform)	`src/content/sdk-catalog.ts`
New tool or parameter changes	`src/tools/register.ts`
Example folders / SDK file layout within existing repos	Nothing (discovered live from GitHub, cached 4h)
Doc page content	Nothing (fetched live via Algolia / llms.txt / GitHub)

License

MIT

Available Tools

5 tools

get_docA

Read-onlyIdempotent

Inspect

Fetch the full content of a MetaMask Embedded Wallets documentation page. Use after search_docs to read the actual doc. Tries Algolia, then llms.txt, then GitHub raw MDX as fallbacks.

ParametersJSON Schema

Name	Required	Description	Default
`url`	Yes	A docs.metamask.io URL, e.g. https://docs.metamask.io/embedded-wallets/sdk/react/

TDQS

A4.4/5.0

Behavior4/5

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

The description adds valuable behavioral context beyond what annotations provide. While annotations already indicate read-only, idempotent, and open-world characteristics, the description reveals the multi-source fallback strategy ('Tries Algolia, then llms.txt, then GitHub raw MDX as fallbacks'), which helps the agent understand reliability and performance implications. No contradiction with annotations exists.

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 perfectly concise with three tightly focused sentences. The first states the core purpose, the second provides usage guidance, and the third reveals implementation behavior. Every sentence earns its place with no wasted words, and the information is front-loaded effectively.

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?

Given the tool's moderate complexity (single parameter, read-only operation with fallback behavior) and comprehensive annotations, the description provides good contextual coverage. It explains the purpose, usage sequencing, and implementation strategy. The main gap is the lack of output information (no output schema), but the description compensates somewhat by indicating it fetches 'full content.'

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?

With 100% schema description coverage, the input schema already fully documents the single 'url' parameter. The description doesn't add any parameter-specific information beyond what's in the schema, so it meets the baseline expectation but doesn't provide additional semantic context about the parameter.

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 the specific action ('Fetch the full content') and resource ('MetaMask Embedded Wallets documentation page'), distinguishing it from sibling tools like search_docs (which finds pages) and get_sdk_reference/get_example (which target different content types). It precisely defines what the tool does.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explicitly states when to use this tool ('Use after search_docs to read the actual doc'), providing clear sequencing guidance. It also distinguishes it from search_docs by indicating this is for reading full content after searching, establishing a clear workflow relationship.

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

get_exampleA

Read-onlyIdempotent

Inspect

Fetch the complete source code of a Web3Auth integration example from GitHub. Returns all source files needed to understand how the integration works. Examples are the PRIMARY reference for integration patterns — always prefer example code over raw SDK source.

ParametersJSON Schema

Name	Required	Description
`name`	No	Example name, e.g. 'React Quick Start' or 'Android Firebase'
`platform`	No	Filter by platform
`chain`	No	Filter by blockchain family
`category`	No	Filter by category
`auth_method`	No	Filter by auth method, e.g. 'auth0', 'firebase', 'google', 'grouped'

TDQS

A4.4/5.0

Behavior4/5

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and openWorldHint=true, covering safety and idempotency. The description adds valuable context beyond this: it specifies that the tool fetches from GitHub and returns all source files, and emphasizes the importance of examples as primary references. There is no contradiction with annotations, and the description enhances understanding of the tool's behavior without repeating structured 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?

The description is appropriately sized and front-loaded: the first sentence clearly states the tool's purpose, followed by a sentence on return value, and a final sentence providing usage guidance. Every sentence adds value without redundancy, making it efficient and well-structured.

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?

Given the tool's complexity (5 parameters, no output schema) and rich annotations (readOnlyHint, idempotentHint, openWorldHint), the description is largely complete. It covers purpose, usage guidelines, and behavioral context. However, it doesn't detail the return format (e.g., file structure or pagination), which could be useful since there's no output schema, leaving a minor gap.

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 all 5 parameters with descriptions and enums. The description does not add any parameter-specific information beyond what the schema provides, such as syntax or format details. However, it implies filtering capabilities through 'Fetch the complete source code of a Web3Auth integration example,' which aligns with the schema but doesn't offer additional semantics.

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 the specific action ('fetch the complete source code'), resource ('Web3Auth integration example from GitHub'), and scope ('all source files needed to understand how the integration works'). It explicitly distinguishes this tool from siblings by stating 'Examples are the PRIMARY reference for integration patterns — always prefer example code over raw SDK source,' which differentiates it from get_sdk_reference.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides explicit guidance on when to use this tool versus alternatives: 'always prefer example code over raw SDK source' directly contrasts with get_sdk_reference. It also implies context by positioning examples as the primary reference for integration patterns, though it doesn't explicitly mention other siblings like get_doc or search_community.

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

get_sdk_referenceA

Read-onlyIdempotent

Inspect

Fetch SDK source code (type definitions, interfaces, hooks) from the open-source Web3Auth SDK repos. Use for REFERENCE and DEBUGGING only — to verify exact type shapes, constructor signatures, available hooks, and error types. Do NOT use this to discover features; many SDK options are internal or legacy. Always use get_example first for integration patterns.

ParametersJSON Schema

Name	Required	Description	Default
`platform`	Yes	Target platform SDK to fetch source for
`module`	No	Specific SDK module to fetch, e.g. 'core-types', 'react-hooks', 'modal-types', 'main-class'. Omit to get default type definitions. Call without module first to see available modules.
`focus`	No	What kind of source to focus on. 'types' = interfaces/types (default, most useful). 'hooks' = React hooks / Vue composables. 'errors' = error types. 'main-class' = SDK implementation. 'all' = everything.	types

TDQS

A4.4/5.0

Behavior4/5

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and openWorldHint=true, indicating safe, repeatable operations. The description adds valuable context beyond this by specifying the tool's purpose for reference/debugging only, warning about internal/legacy SDK options, and recommending get_example for integration patterns. It doesn't contradict annotations, and the added context helps the agent understand behavioral nuances not covered by structured fields.

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 front-loaded with the core purpose and usage guidelines in the first sentence, followed by specific instructions and warnings. Every sentence adds value—clarifying the tool's scope, restrictions, and alternatives—with no redundant or unnecessary information. It efficiently conveys critical information in a compact form.

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?

Given the tool's complexity (fetching SDK source code with multiple parameters) and rich annotations (readOnlyHint, idempotentHint, openWorldHint), the description is largely complete. It covers purpose, usage guidelines, and behavioral context effectively. However, without an output schema, it doesn't describe return values or format, which is a minor gap. The annotations and schema compensate well, but the description could slightly enhance completeness by hinting at output structure.

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 already documents all parameters thoroughly. The description adds some semantic context by mentioning 'type definitions, interfaces, hooks, and error types,' which aligns with the 'focus' parameter options, but doesn't provide additional syntax or format details beyond what the schema specifies. This meets the baseline for 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 clearly states the specific action ('Fetch SDK source code') and resource ('from the open-source Web3Auth SDK repos'), distinguishing it from sibling tools like get_doc or get_example. It explicitly mentions fetching type definitions, interfaces, hooks, and error types, providing a precise scope that differentiates it from other tools that might return documentation or examples.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides explicit guidance on when to use this tool ('for REFERENCE and DEBUGGING only') and when not to use it ('Do NOT use this to discover features'). It also names an alternative tool ('Always use get_example first for integration patterns'), clearly differentiating usage contexts from siblings like get_example, get_doc, search_community, and search_docs.

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

search_communityA

Read-onlyIdempotent

Inspect

Search or fetch posts from the MetaMask Embedded Wallets community forum (builder.metamask.io). Use for troubleshooting real user issues, finding workarounds, and checking if an issue is known. Provide a query to search or a topic_id to read the full discussion.

ParametersJSON Schema

Name	Required	Description	Default
`query`	No	Search query, e.g. 'popup blocked safari', 'JWT error', 'Android unstable connection'
`topic_id`	No	Discourse topic ID to fetch the full discussion thread

TDQS

A4.4/5.0

Behavior4/5

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

Annotations already indicate this is a read-only, idempotent, and open-world operation, which the description doesn't contradict. The description adds valuable context beyond annotations by specifying the forum source (builder.metamask.io) and the two distinct behavioral modes (search vs. fetch), though it doesn't mention rate limits or authentication needs. With annotations covering core safety traits, this additional context earns a strong score.

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 front-loaded with the core purpose, followed by usage context and parameter guidance in just two sentences. Every sentence earns its place by providing essential information without redundancy, making it highly efficient and well-structured.

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 tool with two parameters, 100% schema coverage, and annotations covering key behavioral traits, the description provides sufficient context by clarifying the forum source and use cases. The lack of an output schema is a minor gap, but the description compensates by explaining what the tool returns (search results or full discussions). It's nearly complete for this complexity level.

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 clear descriptions for both parameters (query and topic_id). The description adds minimal semantic value beyond the schema by mentioning the two modes ('search or fetch'), but doesn't provide additional details like query syntax examples beyond what's in the schema. Given the high schema coverage, the baseline 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 clearly states the specific action ('Search or fetch posts') and target resource ('MetaMask Embedded Wallets community forum'), distinguishing it from sibling tools like search_docs by specifying the forum context. It provides concrete examples of use cases (troubleshooting, finding workarounds, checking known issues), making the purpose unambiguous.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explicitly states when to use this tool ('for troubleshooting real user issues, finding workarounds, and checking if an issue is known') and provides clear alternatives for the two parameter modes ('Provide a query to search or a topic_id to read the full discussion'). This gives the agent precise guidance on selecting between query-based search and topic fetching.

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

search_docsA

Read-onlyIdempotent

Inspect

Search MetaMask Embedded Wallets (Web3Auth) documentation and examples. Use for SDK discovery, feature lookup, and finding relevant examples. Returns doc page links with snippets and matching example projects.

ParametersJSON Schema

Name	Required	Description
`query`	Yes	What you are looking for -- e.g. 'React custom auth', 'Android deep linking', 'JWT grouped connections'
`platform`	No	Filter examples by platform
`chain`	No	Filter examples by blockchain family
`category`	No	Filter examples by category

TDQS

A4/5.0

Behavior3/5

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and openWorldHint=true, covering safety and idempotency. The description adds useful context about what gets returned (doc page links with snippets and matching example projects), which isn't covered by annotations. However, it doesn't mention rate limits, authentication needs, or pagination behavior.

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 perfectly concise with two sentences that each earn their place. The first sentence establishes purpose and scope, while the second describes the return format. No wasted words, and the most important information is front-loaded.

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?

Given the tool's moderate complexity (4 parameters, 3 with enums) and rich annotations, the description is mostly complete. It covers purpose, usage context, and return format. However, without an output schema, it could benefit from more detail about the structure of returned results (e.g., pagination, error handling).

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 all parameters well-documented in the schema. The description doesn't add any parameter-specific information beyond what's already in the schema, so it meets the baseline of 3. The description does imply the tool supports filtering (via platform, chain, category), but this is already explicit in the schema.

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 the tool searches MetaMask Embedded Wallets documentation and examples, specifying the exact resource (documentation and examples) and purpose (SDK discovery, feature lookup, finding examples). It distinguishes from siblings like get_doc (single document), get_example (single example), get_sdk_reference (reference material), and search_community (community content).

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?

The description provides clear context for when to use this tool (SDK discovery, feature lookup, finding examples), but doesn't explicitly state when NOT to use it or name specific alternatives. The sibling tools suggest different use cases, but the description doesn't contrast them directly.

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

A4.4/5.0

Disambiguation5/5

Each tool has a clearly distinct purpose: get_doc retrieves documentation content, get_example fetches example code, get_sdk_reference provides SDK source for debugging, search_community accesses forum discussions, and search_docs performs initial documentation searches. The descriptions explicitly differentiate their roles and use cases, leaving no ambiguity.

Naming Consistency5/5

All tool names follow a consistent verb_noun pattern using snake_case: get_doc, get_example, get_sdk_reference, search_community, and search_docs. This uniformity makes the tool set predictable and easy to understand at a glance.

Tool Count5/5

With 5 tools, the server is well-scoped for its purpose of providing MetaMask Embedded Wallets resources. Each tool serves a specific function (documentation, examples, SDK reference, community, and search), and none feel redundant or missing given the domain of developer support and integration.

Completeness4/5

The tool set covers key areas for developer integration: documentation access, example code, SDK reference, community support, and search functionality. A minor gap exists in not having tools for direct wallet operations or API interactions, but this is reasonable as the server focuses on resource retrieval rather than live wallet management.

Maintenance

ActivityInactive

ResponsivenessSyncing

Resources

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

Zaira Labs Guide A
ai.zairalabs
Trust signals for AI agents: an open agent-readiness standard and developer tool guide. Read-only.
Developer Tools Autonomous Agents AI & Machine Learning
52
Graneth A
com.graneth
Pre-flight check for AI coding agents: hallucinated packages + secrets, 6 ecosystems, no account.
Code Analysis Security Developer Tools
2
Tracea A
io.github.Chriscorp
Tracea — legal identity (Know Your Agent) for AI agents, on-chain. ERC-8004 compatible.
Security Blockchain Web3 & Decentralized Tech
151
Sentinel A
org.448c
Pay-per-call safety checks for AI agents: screen a crypto address or URL before you transact.
Security Blockchain Cryptocurrency
22

Related MCP Servers

BarzKit — Self-custody AI
Blockchain Web3 & Decentralized Tech Autonomous Agents
barzkit
A
license
Not graded
quality
D
maintenance
Self-custody AI agent wallets with passkeys, gasless transactions & programmable permissions (ERC-4337)
Updated 5 months ago (2026-03-22 01:05 UTC)
14
MIT
Privy MCP Serverofficial
Blockchain Cryptocurrency Web3 & Decentralized Tech
privy-io
A
license
B
quality
D
maintenance
Enables AI agents to create wallets, sign transactions, and manage blockchain operations across multiple chains like Ethereum, Solana, and more via Privy.
Updated 7 months ago (2026-02-09 22:08 UTC)
24
2
MIT
ContextEngineofficial
Knowledge & Memory Search Developer Tools
FASTPROD
A
license
A
quality
A
maintenance
Persistent memory and mechanical enforcement for AI coding agents — so they stop repeating your mistakes.
Updated 2 days ago (2026-09-01 14:57 UTC)
21
126
3
Business Source 1.1
chain-signer
Blockchain Cryptocurrency Autonomous Agents
Kevthetech143
A
license
A
quality
B
maintenance
Non-custodial agent wallet with a transaction preflight that decodes an unsigned EVM tx and flags drain patterns (unlimited/large approval, approve-all, token & NFT transferFrom, proxy upgrade, on-chain permit, approvals hidden in multicall) before signing.
Updated 2 months ago (2026-07-06 05:00 UTC)
9
1
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/Web3Auth/web3auth-mcp'

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

MetaMask Embedded Wallets MCP Server

MCP Tools

Skill

Universal install (works with 40+ agents)

MCP Server Setup

Cursor

VS Code (GitHub Copilot)

JetBrains (IntelliJ, PyCharm, WebStorm, Android Studio)

Claude Code CLI

Claude Desktop

ChatGPT Desktop

Windsurf

Kiro (AWS)

Warp Terminal

Cline (VS Code)

Continue.dev

Zed

Antigravity

Xcode (via GitHub Copilot)

Eclipse (via GitHub Copilot)

Neovim (avante.nvim)

Neovim (codecompanion.nvim)

Amp (Sourcegraph)

Goose

5ire

Aider

Codex CLI

Static docs (llms.txt)

Start building

Distribution

Environment Variables

Development

Updating Content

License

Available Tools

Maintenance

Resources

Looking for Admin?

Related MCP Connectors

Related MCP Servers

Privy MCP Serverofficial

ContextEngineofficial

Latest Blog Posts

MCP directory API