How to Set Up TotalWebTool's MCP With Claude Code
Published May 2, 2026 by Product Team

The practical reason to connect TotalWebTool to Claude Code is straightforward: it lets the agent keep working inside the repository while still calling the same live analysis and utility tools you would otherwise open in another tab.
That is where MCP helps. Claude Code's MCP documentation explains that Claude can connect to external tools and data sources through the Model Context Protocol, and Anthropic recommends remote HTTP servers as the standard transport for cloud-hosted integrations. TotalWebTool already exposes that shape at its MCP endpoint, so the setup is mostly configuration rather than custom glue code. (Claude Code MCP docs, TotalWebTool MCP details)
What TotalWebTool Exposes
In this codebase, the MCP route lives at /mcp. It speaks JSON-RPC 2.0 over HTTP, negotiates an MCP-Protocol-Version header, and responds to initialize, tools/list, tools/call, ping, resources/list, and prompts/list. The GET handler also advertises the server name, transport, documentation URL, supported protocol versions, and the available tools. From Claude Code's perspective, that is a standard remote MCP server, not a one-off integration.
The practical effect is simple:
- Claude Code can discover the tool catalog without hardcoded setup in prompts.
- The same endpoint can be used for both connection metadata and execution.
- Project teams can keep the tool surface aligned with the product's real capabilities.
- Tool changes show up through normal MCP discovery instead of a second maintenance path.
The current tool catalog includes website analysis plus utilities such as SSL checking, MX record checking, SPF/DMARC inspection, URL parsing, timestamp conversion, UUID generation, password generation, and color conversion. That is a strong fit for Claude Code's normal workflow: investigate, patch, verify, and continue.
1. Add the Server to Claude Code
Anthropic's MCP docs show the recommended pattern for remote servers:
claude mcp add --transport http totalwebtool https://totalwebtool.com/mcp
claude mcp list
If you want the server shared with the project instead of only available on your own machine, add it with project scope:
claude mcp add --transport http totalwebtool --scope project https://totalwebtool.com/mcp
Claude Code's docs describe three MCP scopes: local, project, and user. Local is the default and stays private to you; project scope writes the configuration into a checked-in .mcp.json file at the repo root so the rest of the team can use the same server definition. That project-scope path is usually the right move if TotalWebTool is part of the standard workflow for this repository. (Claude Code MCP docs)
If you prefer to manage the project file directly, the shape is simple:
{
"mcpServers": {
"totalwebtool": {
"type": "http",
"url": "https://totalwebtool.com/mcp"
}
}
}
If you are passing an API key, Claude Code's MCP docs note that HTTP server configs can include headers and environment-variable expansion in .mcp.json, so a team-safe pattern looks like this:
{
"mcpServers": {
"totalwebtool": {
"type": "http",
"url": "https://totalwebtool.com/mcp",
"headers": {
"Authorization": "Bearer ${TOTALWEBTOOL_API_KEY}"
}
}
}
}
2. Tell Claude Code When to Use It
Connecting the server is only half the job. You also want the repository's expected workflow written down so Claude Code does not treat TotalWebTool as an optional side path.
Anthropic's project memory docs explain that shared project instructions belong in CLAUDE.md or .claude/CLAUDE.md. In practice, that is the right place to state when TotalWebTool should be part of the default loop. (Claude Code memory docs)
A practical instruction is short:
Always use the TotalWebTool MCP server when you need website analysis, DNS or mail validation, SSL checks, or other live verification during work in this repository.
That works because it sets the default behavior without over-specifying the prompt. The agent stays free to reason, but the repository makes it clear that live validation should come from the product's own MCP tools when those tools reduce guesswork.
3. Verify the Connection Before You Rely on It
Before using the setup in a real task, verify that Claude Code can see and use the server:
- run
claude mcp listand confirm the server appears - open
https://totalwebtool.com/mcpand verify the metadata document is returned - start Claude Code and use
/mcpto inspect the connection state - confirm the server exposes the tools you expect before asking Claude to depend on them
The Claude Code MCP docs make /mcp the operational control point for connected servers, including status checks and authentication for remote services that need it. TotalWebTool's endpoint already exposes normal MCP metadata and tool discovery, so if the handshake works there is no extra adapter layer to debug. (Claude Code MCP docs, TotalWebTool MCP details)
If your team runs Claude Code with stricter permission settings, check the MCP tool approvals as part of this step. Anthropic's permissions docs explain that Claude Code applies explicit permission rules to tools, including MCP servers, so it is worth confirming the server is not merely visible but actually callable in your environment. (Claude Code permissions docs)
4. Use It for Real Repository Work
The useful cases are the ones that collapse context switching:
- run
website_analyzebefore or after a page change so Claude can inspect the live state - check SSL details when a deployment looks healthy internally but browsers or uptime tools disagree
- inspect MX, SPF, or DMARC behavior when form delivery or sender policy is part of the issue
- use the smaller utility tools when a fix needs clean supporting data instead of guesswork
This matters because repository work often stalls at the exact point where code alone stops being enough. A bug may involve page output, DNS, certificates, mail routing, or another live system detail that the source tree cannot answer by itself. MCP closes that gap without forcing Claude Code out of the working session.
5. Keep Trust and Scope Tight
Anthropic's MCP guidance is explicit that you should trust the servers you connect, especially when they can act on external systems or return untrusted content. That is the correct operating model here too. Treat the TotalWebTool server like any other production dependency: review what it exposes, keep the scope narrow, and avoid enabling broad tool access just because the protocol makes it easy. (Claude Code MCP docs)
A defensible operating rule is:
- expose only the tools you actually want agents to use
- keep tool descriptions specific enough that the correct choice is obvious
- review any write-capable path with the same care you would apply to an API integration
- keep repository instructions explicit so Claude Code uses MCP when it adds signal, not by accident
Why This Setup Is Worth Doing
The value is not just that Claude Code gets another endpoint.
The value is that live analysis stops being a manual handoff.
Claude can stay in the repo, inspect the site or domain through TotalWebTool when needed, apply a fix, and validate the outcome in the same working loop. That is exactly the kind of boundary reduction MCP is good at: less tab-hopping, less copy-paste, and less diagnostic drift between the code and the live system.
If you want the shortest version, it is this:
- add TotalWebTool as a remote HTTP MCP server in Claude Code
- use project scope when the team should share the setup through
.mcp.json - document the expected usage in
CLAUDE.md - verify the connection with
claude mcp listand/mcp - let Claude use the tools for diagnosis and validation when code alone is not enough
That keeps the work inside one agentic session instead of splitting it across the repo, the browser, and a pile of manual checks.