LeaderboardBack to leaderboard — loading return destination
Opening report…
Loading report overview
M
MCP server
server.example.com/mcp
Tools and resources for your MCP client, with a public quality report and detailed checks.
Protocol
MCP 2025-11-25
Server version
1.0.0
Website
server.example.com
Supports
Tools · Resources
Overall score
90 /100
How is this score calculated?
Server metadata
Loading server metadata
Reviewed90/100
Discoverability
Loading discoverability
Reviewed90/100
Protocol
Loading protocol
Reviewed90/100
Tools
Loading tools
Reviewed90/100
MCP Apps
Loading mcp apps
Reviewed90/100
Tool documentation quality
Loading tool documentation quality
Reviewed90/100
LeaderboardBack to leaderboard — loading return destination
I
inetGeek
inetgeek-mcp.palashbagchi.workers.dev/mcp
Sourced infrastructure comparisons: provider pricing, limits and compliance read from each vendor's own documentation and dated, plus iScore, live DNS/SPF checks and a stack planner.
Sourced infrastructure comparisons: provider pricing, limits and compliance read from each vendor's own documentation and dated, plus iScore, live DNS/SPF checks and a stack planner.
inetGeek is a reference of sourced, dated provider facts. It does not know your user's project; you do. Before planning, estimating or comparing, read the project and pass what you find:
- the platform and runtime it deploys on (wrangler.jsonc, vercel.json, netlify.toml, Dockerfile, package.json scripts and dependencies, framework config) -> `platform` and `framework`;
- providers it already runs (dependencies, env var names such as STRIPE_, DATABASE_URL hosts, DNS and deploy config) -> `already_using`, and anything ruled out -> `exclude`;
- real volumes (monthly pageviews or events, users, emails, requests — from its analytics, logs or dashboards if you can reach them; ask the user if not) -> `units` for estimate_monthly_cost;
- hard requirements (data residency, SOC 2, SSO, cookie-free, self-hosting, which payment providers it takes) -> `security` and filter_providers.
Then: plan_infrastructure reports ties as ties (the pick is only alphabetical) — never present a tie as a recommendation; choose among the equals with what you read in the project. estimate_monthly_cost is inetGeek's arithmetic on published rates, not a quote. An empty cell means undocumented on the vendor's page at the date shown, not a confirmed no. When two of a vendor's own pages disagree, get_ledger shows both quotes and no value is recorded.
Discoverability
0/6 passed0 of 6 passed0/100
Client listings and public setup information.
mcp.json or server-card.json
Either mcp.json or an MCP Server Card declaring this endpoint passes.
The public page could not be checked because of a network error, timeout, or inspection limit.
The title clearly communicates the tool’s action and subject. Keep it concise.
Description86/100
The infrastructure categories inetGeek tracks — one line per URL section ("hosting", "gpu", "databases", "storage", "caching", "vector-db", "data-api", "federation", "auth", "email", "queues", "payments", "cdn", "observability", "ci-cd", "secrets-mgmt", "analytics", "llm-apis", "search", "dns-hosting", "kubernetes", "iac", "backup", "api-gateway", "load-balancing", "realtime", "waf", "data-warehouse", "etl", "media", "sms", "streaming", "feature-flags", "incident-management", "finops", "docs-platforms", "ztna", "model-hosting"), each with its current provider count and the category ids that publish under it (hosting groups frontend-serverless, paas, vps-cloud, managed-hosting and mass-market). The section name is the `category` argument every other tool takes. Call this first if you don't already know which section a provider falls under. Derived from the published provider list, so it can't lag the site.
Describe the returned information so the agent knows whether it will answer the request.
Inputs100/100
This tool declares no inputs, so argument descriptions are not needed.
No output schema is declared. Add one for structured results so clients can interpret returned fields.
Not declared
Original tool metadata
{
"name": "list_categories",
"title": "List inetGeek categories",
"description": "The infrastructure categories inetGeek tracks — one line per URL section (\"hosting\", \"gpu\", \"databases\", \"storage\", \"caching\", \"vector-db\", \"data-api\", \"federation\", \"auth\", \"email\", \"queues\", \"payments\", \"cdn\", \"observability\", \"ci-cd\", \"secrets-mgmt\", \"analytics\", \"llm-apis\", \"search\", \"dns-hosting\", \"kubernetes\", \"iac\", \"backup\", \"api-gateway\", \"load-balancing\", \"realtime\", \"waf\", \"data-warehouse\", \"etl\", \"media\", \"sms\", \"streaming\", \"feature-flags\", \"incident-management\", \"finops\", \"docs-platforms\", \"ztna\", \"model-hosting\"), each with its current provider count and the category ids that publish under it (hosting groups frontend-serverless, paas, vps-cloud, managed-hosting and mass-market). The section name is the `category` argument every other tool takes. Call this first if you don't already know which section a provider falls under. Derived from the published provider list, so it can't lag the site.",
"inputSchema": {
"type": "object",
"properties": {}
},
"annotations": {
"readOnlyHint": true,
"openWorldHint": false,
"idempotentHint": true,
"destructiveHint": false
}
}
The title clearly communicates the tool’s action and subject. Keep it concise.
Description94/100
Every published provider in one category, with its free tier, entry paid price and inetGeek's editorial "best for" line — the orientation call before get_provider. Every figure is the same sourced, dated fact the provider's own page shows; "Not documented" means undocumented as of the page's verification dates, not a confirmed no. `category` is a URL section ("hosting", "gpu", "databases", "storage", "caching", "vector-db", "data-api", "federation", "auth", "email", "queues", "payments", "cdn", "observability", "ci-cd", "secrets-mgmt", "analytics", "llm-apis", "search", "dns-hosting", "kubernetes", "iac", "backup", "api-gateway", "load-balancing", "realtime", "waf", "data-warehouse", "etl", "media", "sms", "streaming", "feature-flags", "incident-management", "finops", "docs-platforms", "ztna", "model-hosting") or a category id (e.g. "paas", "vps-cloud", "object-storage"); providers also_in a category are listed there too, marked as such.
The description explains the capability, when to use it, and what to expect.
Inputs89/100
Input documentation gives an agent enough context to populate the arguments.
category
URL section such as "databases" or "hosting", or a category id such as "vps-cloud"; see list_categories
No output schema is declared. Add one for structured results so clients can interpret returned fields.
Not declared
Original tool metadata
{
"name": "list_providers",
"title": "List providers in a category",
"description": "Every published provider in one category, with its free tier, entry paid price and inetGeek's editorial \"best for\" line — the orientation call before get_provider. Every figure is the same sourced, dated fact the provider's own page shows; \"Not documented\" means undocumented as of the page's verification dates, not a confirmed no. `category` is a URL section (\"hosting\", \"gpu\", \"databases\", \"storage\", \"caching\", \"vector-db\", \"data-api\", \"federation\", \"auth\", \"email\", \"queues\", \"payments\", \"cdn\", \"observability\", \"ci-cd\", \"secrets-mgmt\", \"analytics\", \"llm-apis\", \"search\", \"dns-hosting\", \"kubernetes\", \"iac\", \"backup\", \"api-gateway\", \"load-balancing\", \"realtime\", \"waf\", \"data-warehouse\", \"etl\", \"media\", \"sms\", \"streaming\", \"feature-flags\", \"incident-management\", \"finops\", \"docs-platforms\", \"ztna\", \"model-hosting\") or a category id (e.g. \"paas\", \"vps-cloud\", \"object-storage\"); providers also_in a category are listed there too, marked as such.",
"inputSchema": {
"type": "object",
"$schema": "http://json-schema.org/draft-07/schema#",
"required": [
"category"
],
"properties": {
"category": {
"type": "string",
"description": "URL section such as \"databases\" or \"hosting\", or a category id such as \"vps-cloud\"; see list_categories"
}
}
},
"annotations": {
"readOnlyHint": true,
"openWorldHint": false,
"idempotentHint": true,
"destructiveHint": false
}
}
The title clearly communicates the tool’s action and subject. Keep it concise.
Description97/100
Every inetGeek provider documented as offering a startup credit program, with the amount/eligibility as published, a source, and the date it was checked. Use this to filter for an MVP-stage pick before calling get_provider or get_stack_recommendation for the rest of the decision. Absence from this list means undocumented as of the check, not a confirmed "no program".
The description explains the capability, when to use it, and what to expect.
Inputs100/100
This tool declares no inputs, so argument descriptions are not needed.
No output schema is declared. Add one for structured results so clients can interpret returned fields.
Not declared
Original tool metadata
{
"name": "list_startup_credit_providers",
"title": "List providers with a startup credit program",
"description": "Every inetGeek provider documented as offering a startup credit program, with the amount/eligibility as published, a source, and the date it was checked. Use this to filter for an MVP-stage pick before calling get_provider or get_stack_recommendation for the rest of the decision. Absence from this list means undocumented as of the check, not a confirmed \"no program\".",
"inputSchema": {
"type": "object",
"properties": {}
},
"annotations": {
"readOnlyHint": true,
"openWorldHint": false,
"idempotentHint": true,
"destructiveHint": false
}
}
The title clearly communicates the tool’s action and subject. Keep it concise.
Description96/100
Full-text search over every page inetGeek has published — providers, comparisons, DNS records, tools and stacks. Provider entries also match on the human label of every fact their page documents ("SOC 2", "point-in-time recovery", "startup credits"), so a fact name finds the providers that carry it — use filter_providers to get the values. Returns matching page paths, titles and descriptions. Use get_provider or compare_providers afterward to fetch the full sourced content for a result.
The description explains the capability, when to use it, and what to expect.
Inputs96/100
Input documentation gives an agent enough context to populate the arguments.
query
Free-text search, e.g. "postgres" or "object storage egress"
No output schema is declared. Add one for structured results so clients can interpret returned fields.
Not declared
Original tool metadata
{
"name": "search_infrastructure",
"title": "Search inetGeek",
"description": "Full-text search over every page inetGeek has published — providers, comparisons, DNS records, tools and stacks. Provider entries also match on the human label of every fact their page documents (\"SOC 2\", \"point-in-time recovery\", \"startup credits\"), so a fact name finds the providers that carry it — use filter_providers to get the values. Returns matching page paths, titles and descriptions. Use get_provider or compare_providers afterward to fetch the full sourced content for a result.",
"inputSchema": {
"type": "object",
"$schema": "http://json-schema.org/draft-07/schema#",
"required": [
"query"
],
"properties": {
"query": {
"type": "string",
"description": "Free-text search, e.g. \"postgres\" or \"object storage egress\""
}
}
},
"annotations": {
"readOnlyHint": true,
"openWorldHint": false,
"idempotentHint": true,
"destructiveHint": false
}
}
The title clearly communicates the tool’s action and subject. Keep it concise.
Description98/100
The full sourced fact sheet for one infrastructure provider — pricing, limits and regions, each with a source URL and the date it was last verified against that source — plus its iScore with interval, rank and per-pillar breakdown (see get_provider_score for the criterion-level basis). Use search_infrastructure first if you don't know the exact category/slug.
The description explains the capability, when to use it, and what to expect.
Inputs63/100
Remove validation rules already expressed in this field’s schema; describe its meaning and usage instead.
category
The URL section the provider publishes under — one of "hosting", "gpu", "databases", "storage", "caching", "vector-db", "data-api", "federation", "auth", "email", "queues", "payments", "cdn", "observability", "ci-cd", "secrets-mgmt", "analytics", "llm-apis", "search", "dns-hosting", "kubernetes", "iac", "backup", "api-gateway", "load-balancing", "realtime", "waf", "data-warehouse", "etl", "media", "sms", "streaming", "feature-flags", "incident-management", "finops", "docs-platforms", "ztna", "model-hosting". Note the five hosting sub-types (paas, vps-cloud, …) all publish under "hosting"; list_categories shows which.
Remove validation rules already expressed in this field’s schema; describe its meaning and usage instead.
slug
e.g. "neon", "vercel", "cloudflare-r2"
Explain the meaning of this value, not just its name.
No output schema is declared. Add one for structured results so clients can interpret returned fields.
Not declared
Original tool metadata
{
"name": "get_provider",
"title": "Get a provider fact sheet",
"description": "The full sourced fact sheet for one infrastructure provider — pricing, limits and regions, each with a source URL and the date it was last verified against that source — plus its iScore with interval, rank and per-pillar breakdown (see get_provider_score for the criterion-level basis). Use search_infrastructure first if you don't know the exact category/slug.",
"inputSchema": {
"type": "object",
"$schema": "http://json-schema.org/draft-07/schema#",
"required": [
"category",
"slug"
],
"properties": {
"slug": {
"type": "string",
"description": "e.g. \"neon\", \"vercel\", \"cloudflare-r2\""
},
"category": {
"type": "string",
"description": "The URL section the provider publishes under — one of \"hosting\", \"gpu\", \"databases\", \"storage\", \"caching\", \"vector-db\", \"data-api\", \"federation\", \"auth\", \"email\", \"queues\", \"payments\", \"cdn\", \"observability\", \"ci-cd\", \"secrets-mgmt\", \"analytics\", \"llm-apis\", \"search\", \"dns-hosting\", \"kubernetes\", \"iac\", \"backup\", \"api-gateway\", \"load-balancing\", \"realtime\", \"waf\", \"data-warehouse\", \"etl\", \"media\", \"sms\", \"streaming\", \"feature-flags\", \"incident-management\", \"finops\", \"docs-platforms\", \"ztna\", \"model-hosting\". Note the five hosting sub-types (paas, vps-cloud, …) all publish under \"hosting\"; list_categories shows which."
}
}
},
"annotations": {
"readOnlyHint": true,
"openWorldHint": false,
"idempotentHint": true,
"destructiveHint": false
}
}
Expand internal abbreviations and remove technical prefixes from the display title.
Description95/100
inetGeek's iScore for one provider: 0–100 against its category peers with an 80% interval and rank, the six pillars (price, capacity, capability, trust, evidence, adoption) each with its interval, weight and coverage, every scored criterion with the fact it was read from and the peer median it was measured against, and — for a provider asking how to score higher — the criteria its peers document that it does not. Computed at build from sourced facts by rules published at /iscore/; not a provider claim, not a benchmark, and not comparable across categories. Always report the interval with the number: a thin record is pulled toward the category middle with a wide band, and that band is the finding. `category` here is a CATEGORY ID ("database", "paas", "llm-api"), not a URL section — list_categories shows both.
The description explains the capability, when to use it, and what to expect.
Inputs75/100
Clarify units, where to obtain this value, or conventions not already expressed in the schema.
category
Category id such as "database", "paas", "object-storage" — the canonical category, or one the provider is also_in
Clear enough to supply this argument.
provider
Provider id or name, e.g. "neon" or "Neon"
Clarify units, where to obtain this value, or conventions not already expressed in the schema.
No output schema is declared. Add one for structured results so clients can interpret returned fields.
Not declared
Original tool metadata
{
"name": "get_provider_score",
"title": "Get a provider's iScore and what moves it",
"description": "inetGeek's iScore for one provider: 0–100 against its category peers with an 80% interval and rank, the six pillars (price, capacity, capability, trust, evidence, adoption) each with its interval, weight and coverage, every scored criterion with the fact it was read from and the peer median it was measured against, and — for a provider asking how to score higher — the criteria its peers document that it does not. Computed at build from sourced facts by rules published at /iscore/; not a provider claim, not a benchmark, and not comparable across categories. Always report the interval with the number: a thin record is pulled toward the category middle with a wide band, and that band is the finding. `category` here is a CATEGORY ID (\"database\", \"paas\", \"llm-api\"), not a URL section — list_categories shows both.",
"inputSchema": {
"type": "object",
"$schema": "http://json-schema.org/draft-07/schema#",
"required": [
"category",
"provider"
],
"properties": {
"category": {
"type": "string",
"description": "Category id such as \"database\", \"paas\", \"object-storage\" — the canonical category, or one the provider is also_in"
},
"provider": {
"type": "string",
"description": "Provider id or name, e.g. \"neon\" or \"Neon\""
}
}
},
"annotations": {
"readOnlyHint": true,
"openWorldHint": false,
"idempotentHint": true,
"destructiveHint": false
}
}
The title clearly communicates the tool’s action and subject. Keep it concise.
Description97/100
Every peer in a provider's category ranked by iScore — the same list as the site's /{section}/{slug}/alternatives/ page — each with its score and interval, free tier, entry price, editorial best-for line, and up to two sourced facts where it differs from the provider named. For an architect choosing a substitute; use get_provider_score on any row for the breakdown, compare_providers where a curated pair exists. Ranks whose intervals overlap are an ordering, not a finding, and are marked. `category` is a CATEGORY ID ("database", "paas"), not a URL section.
The description explains the capability, when to use it, and what to expect.
Inputs94/100
Input documentation gives an agent enough context to populate the arguments.
category
Category id such as "database" or "object-storage" — see list_categories
Clear enough to supply this argument.
provider
Provider id or name to find alternatives to, e.g. "neon"
No output schema is declared. Add one for structured results so clients can interpret returned fields.
Not declared
Original tool metadata
{
"name": "list_alternatives",
"title": "Alternatives to a provider, ranked by iScore",
"description": "Every peer in a provider's category ranked by iScore — the same list as the site's /{section}/{slug}/alternatives/ page — each with its score and interval, free tier, entry price, editorial best-for line, and up to two sourced facts where it differs from the provider named. For an architect choosing a substitute; use get_provider_score on any row for the breakdown, compare_providers where a curated pair exists. Ranks whose intervals overlap are an ordering, not a finding, and are marked. `category` is a CATEGORY ID (\"database\", \"paas\"), not a URL section.",
"inputSchema": {
"type": "object",
"$schema": "http://json-schema.org/draft-07/schema#",
"required": [
"category",
"provider"
],
"properties": {
"category": {
"type": "string",
"description": "Category id such as \"database\" or \"object-storage\" — see list_categories"
},
"provider": {
"type": "string",
"description": "Provider id or name to find alternatives to, e.g. \"neon\""
}
}
},
"annotations": {
"readOnlyHint": true,
"openWorldHint": false,
"idempotentHint": true,
"destructiveHint": false
}
}
The title clearly communicates the tool’s action and subject. Keep it concise.
Description78/100
inetGeek's sourced side-by-side comparison of two providers, where one exists — real differences computed from each provider's own published facts, never templated prose. Pair order doesn't matter; both orderings are tried.
Describe the returned information so the agent knows whether it will answer the request.
Inputs71/100
Clarify units, where to obtain this value, or conventions not already expressed in the schema.
a
First provider slug, e.g. "neon"
Clarify units, where to obtain this value, or conventions not already expressed in the schema.
The title clearly communicates the tool’s action and subject. Keep it concise.
Description84/100
Every side-by-side comparison inetGeek has published, optionally only those involving one provider — so an agent learns which pairs exist before calling compare_providers, instead of discovering a pair is unpublished by trying it. Only pairs that clear the site's sourcing quality gate appear.
Describe the returned information so the agent knows whether it will answer the request.
Inputs50/100
Clarify units, where to obtain this value, or conventions not already expressed in the schema.
provider
Provider slug to restrict to, e.g. "neon"
Clarify units, where to obtain this value, or conventions not already expressed in the schema.
No output schema is declared. Add one for structured results so clients can interpret returned fields.
Not declared
Original tool metadata
{
"name": "list_comparisons",
"title": "List published comparisons",
"description": "Every side-by-side comparison inetGeek has published, optionally only those involving one provider — so an agent learns which pairs exist before calling compare_providers, instead of discovering a pair is unpublished by trying it. Only pairs that clear the site's sourcing quality gate appear.",
"inputSchema": {
"type": "object",
"$schema": "http://json-schema.org/draft-07/schema#",
"properties": {
"provider": {
"type": "string",
"description": "Provider slug to restrict to, e.g. \"neon\""
}
}
},
"annotations": {
"readOnlyHint": true,
"openWorldHint": false,
"idempotentHint": true,
"destructiveHint": false
}
}
The title clearly communicates the tool’s action and subject. Keep it concise.
Description94/100
Every host that publishes real support for a given framework or runtime, ordered by strength of documentation (a dedicated deployment guide first, a generic one second — there is no numeric score). Each row carries the entry paid plan price. This is the tool for 'what should I deploy X on' — cross-check a candidate's free tier and startup-credit-program facts with get_provider before deciding an MVP-stage pick.
The description explains the capability, when to use it, and what to expect.
Inputs75/100
Remove validation rules already expressed in this field’s schema; describe its meaning and usage instead.
No output schema is declared. Add one for structured results so clients can interpret returned fields.
Not declared
Original tool metadata
{
"name": "get_stack_recommendation",
"title": "Get hosting recommendations for a framework",
"description": "Every host that publishes real support for a given framework or runtime, ordered by strength of documentation (a dedicated deployment guide first, a generic one second — there is no numeric score). Each row carries the entry paid plan price. This is the tool for 'what should I deploy X on' — cross-check a candidate's free tier and startup-credit-program facts with get_provider before deciding an MVP-stage pick.",
"inputSchema": {
"type": "object",
"$schema": "http://json-schema.org/draft-07/schema#",
"required": [
"framework"
],
"properties": {
"framework": {
"type": "string",
"description": "e.g. \"nextjs\", \"astro\", \"django\", \"wordpress\", \"laravel\", \"nodejs\", \"nuxt\", \"sveltekit\", \"ghost\", \"n8n\""
}
}
},
"annotations": {
"readOnlyHint": true,
"openWorldHint": false,
"idempotentHint": true,
"destructiveHint": false
}
}
The title clearly communicates the tool’s action and subject. Keep it concise.
Description92/100
inetGeek's /plan/ planner: one suggested starting provider per layer — the cheapest with a documented free tier or a clean USD starting price, ranked by the provider's own facts, never a quality score — with its editorial reason and a floor total. THE TOTAL IS A FLOOR, NOT A PROJECTION: it sums documented entry points ($0 for a real free tier), and a layer whose pricing is usage-based with no flat minimum is listed as excluded, never counted as free; traffic, storage and usage move every number upward (use estimate_monthly_cost for a volume). Pick a stage or name layers explicitly; each stage is a superset of the one before it, and `scale` is most layers rather than all of them. Security requirements re-pick every layer whose providers document those criteria, and say so when no candidate satisfies every requirement rather than picking one anyway. PASS THE PROJECT'S CONTEXT: read its config and dependencies first (wrangler.jsonc, vercel.json, package.json, env var names, Dockerfile) and give `already_using` (providers it runs today), `platform` (the vendor it deploys on) and `exclude`. Without them most layers are TIES — every provider documents a free tier and the pick is only the alphabetically first — and the tool says so layer by layer rather than presenting it as a recommendation. With them, a layer you already cover is left alone, and a tie is broken toward providers on your own platform.
The description explains the capability, when to use it, and what to expect.
Inputs93/100
Remove validation rules already expressed in this field’s schema; describe its meaning and usage instead.
stage
One of "idea", "mvp", "growth", "scale", "enterprise". Each stage is a superset of the one before it; enterprise selects the same layers as scale and differs by requirement, not by layer. Ignored when `layers` is given.
Remove validation rules already expressed in this field’s schema; describe its meaning and usage instead.
Remove validation rules already expressed in this field’s schema; describe its meaning and usage instead.
security
Requirements every pick must document as satisfied: ssoSaml, scimProvisioning, mfa, auditLogs, soc2, iso27001, hipaaEligible, gdprDataResidency, pciDss
Clear enough to supply this argument.
framework
Optional application or runtime — "nextjs", "astro", "django", "laravel", "wordpress", "nodejs", "nuxt", "sveltekit", "ghost", "n8n". Appends the hosts that document real support for it, so one call answers "what does a Next.js project at MVP stage need, and who runs it".
Clear enough to supply this argument.
already_using
Providers the project ALREADY uses, by id or name — "cloudflare-pages", "stripe", "Neon". A layer one of them covers is reported as covered and left out of the floor; the rest of the plan is built around them. Find the id with search_infrastructure or list_providers.
Clear enough to supply this argument.
platform
The platform the project runs on, as a vendor name: "cloudflare", "aws", "google", "microsoft", "vercel", "digitalocean". Where that vendor sells a provider in a layer it is preferred, because one platform is one bill, one login and one network. Matched on the registrable domain of each provider's homepage.
Clear enough to supply this argument.
exclude
Providers the project cannot or will not use (ids or names), e.g. for a licensing, residency or vendor-lock-in reason. Never picked.
No output schema is declared. Add one for structured results so clients can interpret returned fields.
Not declared
Original tool metadata
{
"name": "plan_infrastructure",
"title": "Plan an infrastructure stack",
"description": "inetGeek's /plan/ planner: one suggested starting provider per layer — the cheapest with a documented free tier or a clean USD starting price, ranked by the provider's own facts, never a quality score — with its editorial reason and a floor total. THE TOTAL IS A FLOOR, NOT A PROJECTION: it sums documented entry points ($0 for a real free tier), and a layer whose pricing is usage-based with no flat minimum is listed as excluded, never counted as free; traffic, storage and usage move every number upward (use estimate_monthly_cost for a volume). Pick a stage or name layers explicitly; each stage is a superset of the one before it, and `scale` is most layers rather than all of them. Security requirements re-pick every layer whose providers document those criteria, and say so when no candidate satisfies every requirement rather than picking one anyway. PASS THE PROJECT'S CONTEXT: read its config and dependencies first (wrangler.jsonc, vercel.json, package.json, env var names, Dockerfile) and give `already_using` (providers it runs today), `platform` (the vendor it deploys on) and `exclude`. Without them most layers are TIES — every provider documents a free tier and the pick is only the alphabetically first — and the tool says so layer by layer rather than presenting it as a recommendation. With them, a layer you already cover is left alone, and a tie is broken toward providers on your own platform.",
"inputSchema": {
"type": "object",
"$schema": "http://json-schema.org/draft-07/schema#",
"properties": {
"stage": {
"type": "string",
"description": "One of \"idea\", \"mvp\", \"growth\", \"scale\", \"enterprise\". Each stage is a superset of the one before it; enterprise selects the same layers as scale and differs by requirement, not by layer. Ignored when `layers` is given."
},
"layers": {
"type": "array",
"items": {
"type": "string"
},
"description": "Layer keys to plan: hosting, database, storage, auth, email, observability, queues, cdn, caching, vector-db, secrets, ci-cd, llm, gpu, data-api, federation, analytics, payments, search, dns-hosting, kubernetes, iac, backup, api-gateway, load-balancing, realtime, waf, data-warehouse, etl, media, sms, streaming, feature-flags, incident-management, finops, docs, ztna, model-hosting"
},
"exclude": {
"type": "array",
"items": {
"type": "string"
},
"description": "Providers the project cannot or will not use (ids or names), e.g. for a licensing, residency or vendor-lock-in reason. Never picked."
},
"platform": {
"type": "string",
"description": "The platform the project runs on, as a vendor name: \"cloudflare\", \"aws\", \"google\", \"microsoft\", \"vercel\", \"digitalocean\". Where that vendor sells a provider in a layer it is preferred, because one platform is one bill, one login and one network. Matched on the registrable domain of each provider's homepage."
},
"security": {
"type": "array",
"items": {
"type": "string"
},
"description": "Requirements every pick must document as satisfied: ssoSaml, scimProvisioning, mfa, auditLogs, soc2, iso27001, hipaaEligible, gdprDataResidency, pciDss"
},
"framework": {
"type": "string",
"description": "Optional application or runtime — \"nextjs\", \"astro\", \"django\", \"laravel\", \"wordpress\", \"nodejs\", \"nuxt\", \"sveltekit\", \"ghost\", \"n8n\". Appends the hosts that document real support for it, so one call answers \"what does a Next.js project at MVP stage need, and who runs it\"."
},
"already_using": {
"type": "array",
"items": {
"type": "string"
},
"description": "Providers the project ALREADY uses, by id or name — \"cloudflare-pages\", \"stripe\", \"Neon\". A layer one of them covers is reported as covered and left out of the floor; the rest of the plan is built around them. Find the id with search_infrastructure or list_providers."
}
}
},
"annotations": {
"readOnlyHint": true,
"openWorldHint": false,
"idempotentHint": true,
"destructiveHint": false
}
}
The title clearly communicates the tool’s action and subject. Keep it concise.
Description97/100
What each provider that publishes a per-volume price would charge a month at the volume you state — plan fee plus any overage, cheapest first, each with the plan, the formula, the vendor page it came from and the date it was read. This is INETGEEK'S ARITHMETIC ON PUBLISHED RATES, not a quote and not a projection: taxes, currency, annual discounts and a vendor's own definition of its unit are outside it, and it says so beside every figure. Covers web analytics (pageviews or events), email (emails sent a month) and auth (monthly active users) — see the `unit` argument; a provider absent from the list has no readable per-volume price on file, which says nothing about its price — use get_provider. Get the volume from the project (its analytics, logs or dashboards) rather than guessing, and say which unit it is: a vendor that counts events is not counting pageviews (Umami counts each saved event property as another event; Traks's own page counts a pageview as about two events — pass `events_per_pageview` for those plans).
The description explains the capability, when to use it, and what to expect.
Inputs95/100
Remove validation rules already expressed in this field’s schema; describe its meaning and usage instead.
category
URL section or category id to price, e.g. "analytics". Omit for every category with per-volume prices on file.
Clear enough to supply this argument.
units
The monthly volume, in the unit named by `unit`.
Remove validation rules already expressed in this field’s schema; describe its meaning and usage instead.
unit
What `units` counts: pageviews or events (web analytics), emails sent a month (email), or monthly active users (auth). Only pageviews and events are ever converted into each other, with `events_per_pageview`, and the output says so.
Clear enough to supply this argument.
events_per_pageview
Events recorded per pageview, used only to compare a pageviews figure against plans that bill in events (or the reverse). 1 means a bare pageview and no custom events.
Clear enough to supply this argument.
sites
How many websites the plan must cover. Plans with a stated lower cap are skipped; plans that state no site cap are kept and flagged.
No output schema is declared. Add one for structured results so clients can interpret returned fields.
Not declared
Original tool metadata
{
"name": "estimate_monthly_cost",
"title": "Estimate monthly cost at a stated volume",
"description": "What each provider that publishes a per-volume price would charge a month at the volume you state — plan fee plus any overage, cheapest first, each with the plan, the formula, the vendor page it came from and the date it was read. This is INETGEEK'S ARITHMETIC ON PUBLISHED RATES, not a quote and not a projection: taxes, currency, annual discounts and a vendor's own definition of its unit are outside it, and it says so beside every figure. Covers web analytics (pageviews or events), email (emails sent a month) and auth (monthly active users) — see the `unit` argument; a provider absent from the list has no readable per-volume price on file, which says nothing about its price — use get_provider. Get the volume from the project (its analytics, logs or dashboards) rather than guessing, and say which unit it is: a vendor that counts events is not counting pageviews (Umami counts each saved event property as another event; Traks's own page counts a pageview as about two events — pass `events_per_pageview` for those plans).",
"inputSchema": {
"type": "object",
"$schema": "http://json-schema.org/draft-07/schema#",
"required": [
"units"
],
"properties": {
"unit": {
"enum": [
"pageviews",
"events",
"emails",
"mau"
],
"type": "string",
"default": "pageviews",
"description": "What `units` counts: pageviews or events (web analytics), emails sent a month (email), or monthly active users (auth). Only pageviews and events are ever converted into each other, with `events_per_pageview`, and the output says so."
},
"sites": {
"type": "integer",
"maximum": 9007199254740991,
"description": "How many websites the plan must cover. Plans with a stated lower cap are skipped; plans that state no site cap are kept and flagged.",
"exclusiveMinimum": 0
},
"units": {
"type": "number",
"description": "The monthly volume, in the unit named by `unit`.",
"exclusiveMinimum": 0
},
"category": {
"type": "string",
"description": "URL section or category id to price, e.g. \"analytics\". Omit for every category with per-volume prices on file."
},
"events_per_pageview": {
"type": "number",
"default": 1,
"description": "Events recorded per pageview, used only to compare a pageviews figure against plans that bill in events (or the reverse). 1 means a bare pageview and no custom events.",
"exclusiveMinimum": 0
}
}
},
"annotations": {
"readOnlyHint": true,
"openWorldHint": false,
"idempotentHint": true,
"destructiveHint": false
}
}
Shorten the title to an action and subject; move usage details into the description.
Description88/100
Every provider fact that moved — a price or limit that changed (before, after, source, date), a fact newly sourced, or a provider newly published — derived from the git history of the site data, so it cannot disagree with the pages. Value changes are listed first: a price that moved is the news, a fact newly sourced is inventory. Ask "what changed since I last planned" with `since`; narrow to one provider with `provider`. Returns the most recent entries (the feed carries the last 100).
The description explains the capability, when to use it, and what to expect.
Inputs75/100
Remove validation rules already expressed in this field’s schema; describe its meaning and usage instead.
since
ISO date (YYYY-MM-DD); only entries on or after it
Remove validation rules already expressed in this field’s schema; describe its meaning and usage instead.
provider
Provider slug, e.g. "neon"
Remove validation rules already expressed in this field’s schema; describe its meaning and usage instead.
No output schema is declared. Add one for structured results so clients can interpret returned fields.
Not declared
Original tool metadata
{
"name": "get_changelog",
"title": "What changed on inetGeek",
"description": "Every provider fact that moved — a price or limit that changed (before, after, source, date), a fact newly sourced, or a provider newly published — derived from the git history of the site data, so it cannot disagree with the pages. Value changes are listed first: a price that moved is the news, a fact newly sourced is inventory. Ask \"what changed since I last planned\" with `since`; narrow to one provider with `provider`. Returns the most recent entries (the feed carries the last 100).",
"inputSchema": {
"type": "object",
"$schema": "http://json-schema.org/draft-07/schema#",
"properties": {
"since": {
"type": "string",
"description": "ISO date (YYYY-MM-DD); only entries on or after it"
},
"provider": {
"type": "string",
"description": "Provider slug, e.g. \"neon\""
}
}
},
"annotations": {
"readOnlyHint": true,
"openWorldHint": false,
"idempotentHint": true,
"destructiveHint": false
}
}
Align the title with the capability actually described by this tool.
Description93/100
inetGeek's reference page for one DNS record type or email-authentication mechanism, as text — what it does, how it behaves, and the common mistakes. Reference text, not a live lookup; use check_dns for a domain's actual records. Types: a-record, aaaa-record, cname-record, mx-record, txt-record, ns-record, soa-record, caa-record, ptr-record, srv-record, alias-record, wildcard-record, glue-records, spf, dkim, dmarc, dnssec, ttl, mta-sts, bimi, email-authentication.
The description explains the capability, when to use it, and what to expect.
Inputs50/100
Explain the meaning of this value, not just its name.
type
e.g. "cname", "mx-record", "spf", "dmarc", "ttl"
Explain the meaning of this value, not just its name.
No output schema is declared. Add one for structured results so clients can interpret returned fields.
Not declared
Original tool metadata
{
"name": "get_dns_record",
"title": "DNS record reference",
"description": "inetGeek's reference page for one DNS record type or email-authentication mechanism, as text — what it does, how it behaves, and the common mistakes. Reference text, not a live lookup; use check_dns for a domain's actual records. Types: a-record, aaaa-record, cname-record, mx-record, txt-record, ns-record, soa-record, caa-record, ptr-record, srv-record, alias-record, wildcard-record, glue-records, spf, dkim, dmarc, dnssec, ttl, mta-sts, bimi, email-authentication.",
"inputSchema": {
"type": "object",
"$schema": "http://json-schema.org/draft-07/schema#",
"required": [
"type"
],
"properties": {
"type": {
"type": "string",
"description": "e.g. \"cname\", \"mx-record\", \"spf\", \"dmarc\", \"ttl\""
}
}
},
"annotations": {
"readOnlyHint": true,
"openWorldHint": false,
"idempotentHint": true,
"destructiveHint": false
}
}
The title clearly communicates the tool’s action and subject. Keep it concise.
Description80/100
Queries public DNS-over-HTTPS resolvers for a domain's A/AAAA/CNAME/MX/TXT/NS records right now, via inetGeek's own rate-limited lookup endpoint. Nothing queried is stored.
Describe the returned information so the agent knows whether it will answer the request.
Inputs64/100
Remove validation rules already expressed in this field’s schema; describe its meaning and usage instead.
domain
e.g. "example.com"
Remove validation rules already expressed in this field’s schema; describe its meaning and usage instead.
The title clearly communicates the tool’s action and subject. Keep it concise.
Description86/100
Queries four independent public DNS resolvers for one record and compares their answers, to check whether a change has propagated. Nothing queried is stored.
Describe the returned information so the agent knows whether it will answer the request.
Inputs75/100
Remove validation rules already expressed in this field’s schema; describe its meaning and usage instead.
domain
e.g. "example.com"
Remove validation rules already expressed in this field’s schema; describe its meaning and usage instead.
type
Record type, defaults to "A" — e.g. "A", "AAAA", "CNAME", "MX", "TXT"
Remove validation rules already expressed in this field’s schema; describe its meaning and usage instead.
What inetGeek says it could not find, and what it changed
Align the title with the capability actually described by this tool.
Description81/100
inetGeek's public ledger. Four records an agent cannot get anywhere else: every vendor page that was READ on a stated date and found silent on a criterion, every criterion classed as one a product structurally cannot have, every case where two pages of the SAME vendor contradict each other on a criterion (both quotes and both URLs, with no value recorded — a vendor whose docs say crawlers are dropped while its homepage says they are counted is one), and every change to a published figure with whether the vendor moved it or inetGeek corrected its own reading. A silence record is an observation about one page on one date — it is NOT a statement that the provider lacks the thing, and it must not be reported as one. It exists because comparisons lean on it: a documented criterion outranks a page that was read and does not mention it, and that lean is only fair if the evidence behind it is checkable. A provider whose page says more than was found can send the URL to https://inetgeek.com/contact/ and the row is replaced. Filter to one provider with `provider`, or omit it for the whole ledger.
Describe the returned information so the agent knows whether it will answer the request.
Inputs95/100
Input documentation gives an agent enough context to populate the arguments.
provider
Provider id, e.g. "sentry" or "auth0". Omit for every provider.
No output schema is declared. Add one for structured results so clients can interpret returned fields.
Not declared
Original tool metadata
{
"name": "get_ledger",
"title": "What inetGeek says it could not find, and what it changed",
"description": "inetGeek's public ledger. Four records an agent cannot get anywhere else: every vendor page that was READ on a stated date and found silent on a criterion, every criterion classed as one a product structurally cannot have, every case where two pages of the SAME vendor contradict each other on a criterion (both quotes and both URLs, with no value recorded — a vendor whose docs say crawlers are dropped while its homepage says they are counted is one), and every change to a published figure with whether the vendor moved it or inetGeek corrected its own reading. A silence record is an observation about one page on one date — it is NOT a statement that the provider lacks the thing, and it must not be reported as one. It exists because comparisons lean on it: a documented criterion outranks a page that was read and does not mention it, and that lean is only fair if the evidence behind it is checkable. A provider whose page says more than was found can send the URL to https://inetgeek.com/contact/ and the row is replaced. Filter to one provider with `provider`, or omit it for the whole ledger.",
"inputSchema": {
"type": "object",
"$schema": "http://json-schema.org/draft-07/schema#",
"properties": {
"provider": {
"type": "string",
"description": "Provider id, e.g. \"sentry\" or \"auth0\". Omit for every provider."
}
}
},
"annotations": {
"readOnlyHint": true,
"openWorldHint": false,
"idempotentHint": true,
"destructiveHint": false
}
}
The title clearly communicates the tool’s action and subject. Keep it concise.
Description99/100
Tell inetGeek's maintainer something is wrong, missing or confusing in this MCP server's data or tools — a figure that disagrees with the vendor's own page, a tool that errored or returned something unusable, a provider or criterion you needed and could not get, or a tool whose output misled you. Read by a person; nothing is applied automatically, and a data correction is only made after it is checked against the provider's own published page. For wrong_data, include `provider` and `criterion` (the ids the other tools use) and `evidence_url`: the provider's OWN page that states the correct value — a third-party page cannot be used. For tool problems, name the `tool` and put the arguments you passed and what came back in `observed`. Do NOT include personal data, credentials, API keys, your user's code, or anything from your conversation that your user has not agreed to share: this is stored. This is the only tool on this server that writes anything.
The description explains the capability, when to use it, and what to expect.
Inputs81/100
Remove validation rules already expressed in this field’s schema; describe its meaning and usage instead.
kind
wrong_data: a figure disagrees with the vendor's page. missing_data: a provider, criterion or figure you needed is absent. tool_error: a tool failed. tool_confusing: a tool worked but its output misled you. feature_request: a tool or field that does not exist. other: anything else.
Remove validation rules already expressed in this field’s schema; describe its meaning and usage instead.
message
What is wrong or missing, in plain language. Specific beats long.
Remove validation rules already expressed in this field’s schema; describe its meaning and usage instead.
tool
The tool concerned, e.g. "get_provider".
Remove validation rules already expressed in this field’s schema; describe its meaning and usage instead.
provider
Provider id as the other tools return it, e.g. "neon".
Clarify units, where to obtain this value, or conventions not already expressed in the schema.
criterion
Fact key as the other tools return it, e.g. "free_tier".
Remove validation rules already expressed in this field’s schema; describe its meaning and usage instead.
evidence_url
For wrong_data: the provider's own page that states the correct value.
Clear enough to supply this argument.
observed
What you passed and what came back, or what the page currently shows.
Clear enough to supply this argument.
expected
What you expected instead.
Clear enough to supply this argument.
client
The agent or client product sending this, e.g. "Claude Code". Not a person's name.
Remove validation rules already expressed in this field’s schema; describe its meaning and usage instead.
No output schema is declared. Add one for structured results so clients can interpret returned fields.
Not declared
Original tool metadata
{
"name": "send_feedback",
"title": "Send feedback about the inetGeek MCP server",
"description": "Tell inetGeek's maintainer something is wrong, missing or confusing in this MCP server's data or tools — a figure that disagrees with the vendor's own page, a tool that errored or returned something unusable, a provider or criterion you needed and could not get, or a tool whose output misled you. Read by a person; nothing is applied automatically, and a data correction is only made after it is checked against the provider's own published page. For wrong_data, include `provider` and `criterion` (the ids the other tools use) and `evidence_url`: the provider's OWN page that states the correct value — a third-party page cannot be used. For tool problems, name the `tool` and put the arguments you passed and what came back in `observed`. Do NOT include personal data, credentials, API keys, your user's code, or anything from your conversation that your user has not agreed to share: this is stored. This is the only tool on this server that writes anything.",
"inputSchema": {
"type": "object",
"$schema": "http://json-schema.org/draft-07/schema#",
"required": [
"kind",
"message"
],
"properties": {
"kind": {
"enum": [
"wrong_data",
"missing_data",
"tool_error",
"tool_confusing",
"feature_request",
"other"
],
"type": "string",
"description": "wrong_data: a figure disagrees with the vendor's page. missing_data: a provider, criterion or figure you needed is absent. tool_error: a tool failed. tool_confusing: a tool worked but its output misled you. feature_request: a tool or field that does not exist. other: anything else."
},
"tool": {
"type": "string",
"maxLength": 64,
"description": "The tool concerned, e.g. \"get_provider\"."
},
"client": {
"type": "string",
"maxLength": 64,
"description": "The agent or client product sending this, e.g. \"Claude Code\". Not a person's name."
},
"message": {
"type": "string",
"maxLength": 2000,
"minLength": 10,
"description": "What is wrong or missing, in plain language. Specific beats long."
},
"expected": {
"type": "string",
"maxLength": 1000,
"description": "What you expected instead."
},
"observed": {
"type": "string",
"maxLength": 1000,
"description": "What you passed and what came back, or what the page currently shows."
},
"provider": {
"type": "string",
"pattern": "^[a-z0-9-]{1,64}$",
"description": "Provider id as the other tools return it, e.g. \"neon\"."
},
"criterion": {
"type": "string",
"pattern": "^[a-z0-9_]{1,64}$",
"description": "Fact key as the other tools return it, e.g. \"free_tier\"."
},
"evidence_url": {
"type": "string",
"format": "uri",
"maxLength": 500,
"description": "For wrong_data: the provider's own page that states the correct value."
}
}
},
"annotations": {
"readOnlyHint": false,
"openWorldHint": false,
"idempotentHint": false,
"destructiveHint": false
}
}
Loading score analytics…
Put your MCP to the test
A few tasks worth trying with this server, chosen from its reviewed tools. These have not been run.
01Search inetGeekFull-text search over every page inetGeek has published — providers, comparisons, DNS records, tools and stacks.
02Live DNS lookupQueries public DNS-over-HTTPS resolvers for a domain's A/AAAA/CNAME/MX/TXT/NS records right now, via inetGeek's own rate-limited lookup endpoint.
03List providers in a categoryEvery published provider in one category, with its free tier, entry paid price and inetGeek's editorial "best for" line — the orientation call before get_pro…
04Get hosting recommendations for a frameworkEvery host that publishes real support for a given framework or runtime, ordered by strength of documentation (a dedicated deployment guide first, a generic…
05Filter providers by documented factsProviders that document ALL of the given fact keys, each with that fact's value, source URL and verification date — the way to answer "which databases are HI…
Want to run these tasks against your MCP server with us?
inetGeek setup, tools, quality score, publishing readiness, and alternatives.
How do I add inetGeek to Claude, ChatGPT, or Cursor?
Add inetGeek to Claude, ChatGPT, or Cursor by connecting its remote MCP URL in each client's MCP settings. In Claude, add a custom connector. In ChatGPT, add an MCP app. In Cursor, add an MCP server under Settings. The MCP URL is https://inetgeek-mcp.palashbagchi.workers.dev/mcp.
Is inetGeek MCP ready for ChatGPT and Claude?
As of November 11, 2026, inetGeek scores 96/100 on Manufact's MCP publishing checklist. The scan meets ChatGPT publishing checks and meets Claude publishing checks. Passing these checks does not guarantee marketplace approval.
How clear is inetGeek's MCP tool documentation?
As of November 11, 2026, inetGeek scores 79/100 in Manufact's review of tool titles, descriptions, input and output schemas, and behavior annotations. The review covers 20 of 20 discovered tools. The quality score measures documentation clarity; runtime behavior and marketplace readiness require separate checks.
What are the best alternatives to inetGeek?
As of November 12, 2026, alternatives to inetGeek in developer-tools on the Manufact MCP leaderboard include Speko, Manufact, AgentMail, Context, and Speko.
How can inetGeek improve its MCP documentation?
get_ledger is the lowest-scoring reviewed tool at 65/100. No output schema is declared. Add one for structured results so clients can interpret returned fields. Open its review for feedback and a copyable fix prompt, then rerun the documentation review after updating your tool metadata.
Not your MCP?
Review any public or OAuth MCP server for protocol compatibility, tool documentation, and ChatGPT and Claude publishing readiness. No account required.
Cursor
Grok Bot
Grok
Muse