Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@nod-mcp-server Look up the NOD manifest for demo-restaurant.localhost"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
This is how AI agents will interact with businesses — not by scraping, but by reading structured manifests. This reference MCP server teaches any MCP-compatible client (Claude Desktop, agent frameworks, IDEs) to read a business's nod.json manifest at https://{domain}/.well-known/nod.json and answer real questions about what the business can do: order food, book an appointment, search products, check pricing, and more.
It exposes two tools — lookup_nod and check_capability — and bundles four demo manifests served locally so the demo works out of the box with zero external dependencies.
git clone <this repo> nod-mcp-server
cd nod-mcp-server
npm install
npm run buildRequires Node.js 20+.
Related MCP server: nod-mcp-server
Almost no real sites publish nod.json yet, so this repo bundles four example manifests (restaurant, e-commerce, SaaS, healthcare) and serves them locally.
npm run demo:manifestsYou should see:
NOD demo manifest server listening on http://localhost:3456
http://localhost:3456/demo-restaurant.localhost/nod.json
http://localhost:3456/demo-shop.localhost/nod.json
http://localhost:3456/demo-saas.localhost/nod.json
http://localhost:3456/demo-health.localhost/nod.jsonLeave this terminal running during the demo. The MCP server automatically routes any *.localhost domain to this server.
Open (or create) ~/Library/Application Support/Claude/claude_desktop_config.json on macOS (or %APPDATA%\Claude\claude_desktop_config.json on Windows) and add:
{
"mcpServers": {
"nod": {
"command": "node",
"args": ["/ABSOLUTE/PATH/TO/nod-mcp-server/dist/index.js"]
}
}
}Replace /ABSOLUTE/PATH/TO/nod-mcp-server with the full path to this checkout on your machine (e.g. <your-home>/projects/nod-mcp-server). Restart Claude Desktop. You should now see the nod server listed in Claude's tool picker with two tools: lookup_nod and check_capability.
With the demo manifest server running in one terminal and Claude Desktop configured, paste these prompts into Claude one after another.
Claude calls lookup_nod({ domain: "demo-restaurant.localhost" }) and returns something like:
# Pike Place Noodle House (restaurant)
Hand-pulled noodles, dumplings, and regional Chinese classics...
- URL: https://demo-restaurant.localhost
- Manifest: http://localhost:3456/demo-restaurant.localhost/nod.json
## Declared capabilities
- purchase
- booking
- view_menu
- order_food
- book_table
## Supported actions
- purchase → https://demo-restaurant.localhost/api/orders [auth: api_key]
- booking → https://demo-restaurant.localhost/api/reservations [auth: api_key]
- search → https://demo-restaurant.localhost/api/menu/search [auth: none]Claude calls check_capability({ domain: "demo-restaurant.localhost", action: "order_food" }):
YES — demo-restaurant.localhost supports "order_food".
Manifest declares "order_food" under discovery.mcp_server.capabilities.
Endpoint: POST https://demo-restaurant.localhost/api/orders
Authentication: api_key
Matched via: discovery.mcp_server.capabilities
Constraints:
{ "require_human_confirmation": { "purchases_above": 150, ... },
"rate_limits": { "transactions": { "requests": 10, "period": "minute" } },
"allow_automated_purchases": true }Claude calls lookup_nod({ domain: "demo-shop.localhost" }) and summarizes: product search, pricing, inventory checks, and OAuth2-protected order placement — with a human-confirmation threshold at $500 and a 60-day returns policy.
"Book an appointment at demo-health.localhost — what does that flow require?" → returns the booking endpoint, required fields (patient_name, DOB, reason, provider_id, preferred_date), OAuth2 scopes, and the cancellation policy.
"Does demo-saas.localhost allow automated purchases?" → returns NO with the human-fallback URL, because the manifest sets allow_automated_purchases: false.
lookup_nodInput | Type | Description |
| string | Domain only (no scheme, no path). |
Fetches https://{domain}/.well-known/nod.json, falling back to https://{domain}/nod.json. Returns a structured summary: business identity, declared capabilities, supported actions (with endpoints + auth), API endpoints, and contact methods. Returns a clear "no manifest found" message on failure.
check_capabilityInput | Type | Description |
| string | Domain only. |
| string | Common values: |
Fetches the manifest and checks the action against transactions.capabilities, discovery.mcp_server.capabilities, support.contact.mcp_server.capabilities, and the structural endpoints (transactions.purchase, discovery.search, information.pricing, etc.). Returns a yes/no verdict, the endpoint URL, authentication method, and policy constraints (rate limits, human-confirmation thresholds).
*.localhost routing worksWhen the MCP server receives a domain ending in .localhost, it fetches from http://localhost:3456/{domain}/nod.json instead of the normal well-known URL. This makes the demo self-contained — you can point Claude at demo-restaurant.localhost and get real results without any DNS or HTTPS setup.
Env vars:
NOD_LOCAL_PORT — port the demo manifest server listens on (default 3456)
NOD_LOCAL_MANIFEST_SERVER — base URL the MCP server uses for .localhost lookups (default http://localhost:3456)
NOD_FORCE_LOCAL=1 — route every domain through the local manifest server (useful for contributors testing new example manifests)
Publish a nod.json for your own business using the NOD Protocol spec at opennod.ai/protocol. A minimal, valid manifest takes about 30 minutes to write — and once it's live at https://yourdomain.com/.well-known/nod.json, any agent using this MCP server (or any other NOD-aware client) will be able to discover your business and act on its capabilities.
MIT
Given a domain and an action (e.g. order_food, book_appointment, search_products, get_pricing, view_menu, book_table, check_status, create_account), fetches the business's NOD manifest and reports whether the action is supported, the endpoint URL, authentication requirements, and any policy constraints.
| Name | Required | Description | Default |
|---|---|---|---|
| domain | Yes | The domain to check (e.g. "demo-restaurant.localhost"). | |
| action | Yes | The action to check. Common values: order_food, place_order, view_menu, book_table, book_appointment, search_products, find_provider, get_pricing, check_inventory, check_status, create_account, get_docs, contact_support. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full behavioral disclosure. It explains what the tool does and returns, but does not mention side effects, prerequisites (e.g., domain validity), or that it is read-only.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence covering purpose, input, and output. Very concise with no wasted words, though slightly dense; could be broken into two sentences for readability, but still effective.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema, but description adequately covers return fields (supported status, endpoint, auth, policies). Input is fully described. Missing error handling and sibling differentiation, but sufficient for the tool's simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description adds value by listing common actions, providing concrete examples that aid selection beyond the schema's generic string type.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool checks if an action is supported for a given domain, listing output details. It differentiates from the sibling 'lookup_nod' by focusing on a specific action check.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus 'lookup_nod' or when not to use it. The description only implies usage through examples, lacking explicit context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fetches a business's NOD Protocol manifest from https://{domain}/.well-known/nod.json (or the local demo server for *.localhost domains) and returns a structured summary: business identity, declared capabilities, supported actions, API endpoints, and contact methods.
| Name | Required | Description | Default |
|---|---|---|---|
| domain | Yes | The domain to look up (e.g. "example.com" or "demo-restaurant.localhost"). Do not include scheme or path. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry full behavioral transparency. It discloses the fetch action and return summary but does not address potential failure modes (e.g., domain not found, malformed manifest), rate limits, or authentication requirements. The description is adequate but incomplete for a safe agent invocation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that efficiently conveys the main purpose and key details (URL pattern, return contents). It is front-loaded and includes relevant information without excess words. However, it is somewhat dense and could be split into two sentences for improved readability.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the low complexity (single parameter, no output schema), the description provides sufficient context: it specifies the source URL, the domain format, and the contents of the returned summary. It does not cover error handling or exact output structure, but for a simple lookup tool it is reasonably complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage for the single 'domain' parameter. The description adds context about the URL pattern but reiterates the format constraint already present in the schema. Since schema coverage is high, the baseline of 3 is appropriate; the description does not significantly add meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it fetches a NOD Protocol manifest from a well-known URL and returns a structured summary including business identity, capabilities, actions, endpoints, and contact methods. It uses a specific verb-resource combination and distinguishes itself from the sibling tool 'check_capability' by focusing on the full manifest.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains what the tool does but provides no guidance on when to use it versus the sibling 'check_capability', nor does it mention prerequisites or exclusions. The usage context is implied (looking up a domain's manifest) but lacks explicit alternative differentiation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Both tools deal with NOD manifests but have distinct purposes: lookup_nod retrieves the full manifest and check_capability queries a specific action. No overlap.
Both tool names follow a consistent verb_noun pattern with underscore_case: check_capability and lookup_nod.
Two tools is appropriate for a focused purpose. While minimal, they cover the core operations for querying NOD manifests without unnecessary complexity.
The tools cover the main operations: retrieving the manifest and checking a specific capability. Missing tools for writing or updating manifests, but that seems out of scope.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
What a domain publishes for AI agents: ai-catalog.json, llms.txt, agents.md, robots.txt rules. Free.
Discover what websites across the agentic web can do — query the capabilities.txt registry.
AI agent infrastructure for discovery, authorization, execution, identity, and signed receipts.
Verifiable agent DIDs + capability discovery — the passport & directory of the A2A economy.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/opennod/nod-mcp-server'
If you have feedback or need assistance with the MCP directory API, please join our Discord server