How to Test Your MCP Server โ and Where It's Actually Useful
Publishing an MCP server card is step one. But a card is just a promise โ the question every agent will ask next is: does the endpoint actually work?
Here's how to verify any MCP server in five minutes, using the live endpoint on perceptron.solutions as the example.
Test 1: The protocol handshake
MCP over HTTP is plain JSON-RPC. Three calls tell you everything. First, initialize โ the client and server agree on a protocol version:
curl -X POST https://perceptron.solutions/mcp \
-H 'Content-Type: application/json' \
-d '{"jsonrpc":"2.0","id":1,"method":"initialize","params":{"protocolVersion":"2025-03-26","capabilities":{},"clientInfo":{"name":"test","version":"1.0"}}}'
A healthy server answers with its identity: serverInfo name and version, plus its capabilities. If you get back JSON with a result field, the handshake passed.
Test 2: What can the agent do?
Next, tools/list โ this is what the agent sees when it discovers your site:
curl -X POST https://perceptron.solutions/mcp \
-H 'Content-Type: application/json' \
-d '{"jsonrpc":"2.0","id":2,"method":"tools/list"}'
You should get a tools array with each tool's name, description, and JSON schema. This is the moment your website stops being text and becomes capability.
Test 3: Make it do something
Finally, tools/call โ the real proof. Ask for actual work and inspect the result:
curl -X POST https://perceptron.solutions/mcp \
-H 'Content-Type: application/json' \
-d '{"jsonrpc":"2.0","id":3,"method":"tools/call","params":{"name":"scan_site","arguments":{"url":"https://perceptron.solutions"}}}'
Three calls, under a minute: handshake, discovery, execution. If all three pass, your MCP server is production-ready.
Test 4: A real agent
Curl proves the protocol. A real MCP client proves the experience. Add your server to Claude Code:
claude mcp add --transport http my-site https://your-site.com/mcp
Then run /mcp and look for โ Connected. From there, any agent โ Claude Code, Claude Desktop, Cursor โ can call your tools in conversation, the same way it calls its built-in ones.
Where this is actually useful
๐ Audits and diagnostics
Our scan_site tool is a real example: an agent can run a 22-check site audit from any conversation, no browser needed.
Example: a consultant preparing a pitch says "scan these 20 prospect sites and rank them by agent-readiness" โ the agent calls scan_site twenty times and returns a ranked table. Or a compliance officer asks "has our site's robots.txt changed since last audit?" and gets a live comparison.
๐ Transactions and bookings
Agents don't want to fill forms. An MCP tool for "check availability" or "place order" turns your site into something agents can transact with directly.
Example: a restaurant exposes check_availability and book_table โ a diner tells their assistant "book me a table for four at 7pm Friday near Gastown" and the agent books it without ever opening a browser. Hotels, clinics, and salons work the same way.
๐ Data access
Pricing, inventory, documentation, schedules โ expose them as tools and every AI assistant becomes a front-end to your business.
Example: an equipment supplier exposes get_price and get_stock โ a procurement agent answers "is the X5 in stock in Vancouver and what does it cost?" in seconds. A software vendor exposes search_docs and their docs become instantly answerable by any AI.
๐ค Agent-to-agent workflows
When one agent needs your capability, it discovers it the same way: card โ endpoint โ tools. Your site becomes a building block in other people's automations.
Example: a travel-planning agent composes a trip by calling three unrelated MCP servers โ an airline's search_flights, a hotel chain's check_rooms, and a car rental's get_rates โ each from a different company, each discovered through its own server card.
Want an MCP endpoint for your own site โ tested and live?
We Build Them โ Ask Us