NessGate
Resolve a domain to its published AI interfaces: discovery, readiness, and connection plans.
Should I use this
Quality & Safety
Based on automated analysis of tool definitions and protocol compliance.
Context Cost
This is the approximate number of tokens consumed each time the server's tools are loaded into a model's context. Higher counts reduce the attention available for other tasks.
Install
One-Click Install
Add this to your `claude_desktop_config.json` file:
{
"mcpServers": {
"nessgate": {
"url": "https://nessgate.com/mcp"
}
}
}Remote endpoints
https://nessgate.com/mcpstreamable-httpWhat it can do
Tool inventory
Tools (3)
🟢discover_domain(domain)
Given a domain, read whatever it publishes at the standard machine-discovery locations (llms.txt, /.well-known/ard.json, /.well-known/agent-card.json, /.well-known/api-catalog, ai-info.json, openapi.json, and more) and return one normalized answer. Each resource keeps a sourceUrl pointing back to the domain so the caller can verify. NessGate reads the domain live and stores no discovered domain or resource data; it makes no ownership or safety claim.
Input Schema
{
"type": "object",
"properties": {
"domain": {
"type": "string",
"description": "Registrable domain, e.g. example.com"
}
},
"required": [
"domain"
]
}🟢connect_domain(domain, client)
Given a domain AND the calling client's capabilities, return HOW the client can connect: one outcome (ready | credentials-required | incomplete | broken | no-compatible-method) with a connection plan (protocol, endpoint, transport, version, and the auth metadata the service published — e.g. the OAuth authorize/token endpoints and scopes), or the exact missing field when the service under-publishes. Deterministic matching, no scores. Read-only; credentials stay with the caller and are never sent to NessGate.
Input Schema
{
"type": "object",
"properties": {
"domain": {
"type": "string",
"description": "Registrable domain, e.g. example.com"
},
"client": {
"type": "object",
"description": "The calling client's capabilities. Omit a dimension to accept any. If client/supports is omitted entirely, a broad default (mcp, openapi, a2a) is assumed and the response carries clientAssumed:true.",
"properties": {
"supports": {
"type": "array",
"description": "Protocols the client speaks, each optionally narrowing versions/transports/auth.",
"items": {
"type": "object",
"properties": {
"protocol": {
"type": "string",
"description": "e.g. mcp, openapi, a2a"
},
"versions": {
"type": "array",
"items": {
"type": "string"
}
},
"transports": {
"type": "array",
"items": {
"type": "string"
}
},
"auth": {
"type": "array",
"items": {
"type": "string"
}
}
},
"required": [
"protocol"
]
}
},
"prefer": {
"type": "array",
"description": "Optional cross-protocol tie-break order.",
"items": {
"type": "string"
}
}
}
}
},
"required": [
"domain"
]
}🟢check_readiness(domain)
Given a domain, return each connectable resource it publishes with a readiness assessment (ready | credentials-required | incomplete | broken, with the exact missing field) read from the service's own metadata. Client-agnostic; read-only. Use connect_domain when you know the client's capabilities.
Input Schema
{
"type": "object",
"properties": {
"domain": {
"type": "string",
"description": "Registrable domain, e.g. example.com"
}
},
"required": [
"domain"
]
}Community
Evidence