Skip to main content
Glama
internetdata

InternetData MCP Server

by internetdata
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Remote

InternetData MCP Server

npm license

The official Model Context Protocol server for the InternetData API.

InternetData publishes IP databases: VPN and proxy address space, hosting and CDN ranges, provider catalogs, bogons and more, as gzipped CSV and as MMDB. This server gives an AI agent four read-only tools over them - which databases your organization is licensed for, what is inside one, the digests to verify a copy you already hold, and your recent download history.

Getting Started

We host it at https://mcp.internetdata.io/mcp, and you sign in to it with your InternetData account. It also runs on your own machine from npm. Either way it sees the databases your organization is licensed for. Databases are licensed by contract rather than bought self-serve: see the API documentation or write to dev@internetdata.io.

In Claude

In claude.ai, the desktop app or Cowork, add https://mcp.internetdata.io/mcp as a custom connector and choose Use Claude's published identity when asked. In Claude Code, install our plugin, which adds the server with skills:

/plugin marketplace add internetdata/claude-plugin
/plugin install internetdata@internetdata

Either way you sign in with your InternetData account, and Claude never sees your API key. The steps, the skills and how to disconnect: docs.internetdata.io/integrations/claude.

In any other MCP client

Point it at https://mcp.internetdata.io/mcp. A client that supports MCP authorization signs in the same way. One that doesn't can send a key instead, as Authorization: Bearer your-key.

On your own machine

You need an API key carrying the db.download scope. Add this to your MCP client's config:

{
  "mcpServers": {
    "internetdata": {
      "command": "npx",
      "args": ["-y", "internetdata-mcp"],
      "env": { "INTERNETDATA_API_KEY": "your-key" }
    }
  }
}

Requires Node.js 22 or newer. INTERNETDATA_BASE_URL overrides the endpoint if you need to point somewhere else.

Related MCP server: db-mcp

Tools

Tool

What it answers

list_databases

The databases your organization is licensed for, with the license type and term.

database_metadata

A database's columns, sample rows, row count, build date and file sizes.

database_checksum

The published digests for one database file.

list_downloads

Your organization's recent download attempts, refusals included.

Every tool is read-only.

Two spellings of a database id

list_databases answers a base id and a versions array:

{
  "base": "vpn_ip",
  "standing": "licensed",
  "versions": [{ "id": "vpn_ip_v1", "version": 1, "formats": ["csvgz", "mmdb"] }]
}

The base is what a license names. versions[].id is what a download names, and it is the one database_metadata and database_checksum accept. The tools say so in their own descriptions, so an agent generally gets this right on its own; it is worth knowing when you read a transcript where one was refused.

There is no download tool, deliberately

The published builds run to several GB, which is not something an agent should pull into a conversation. database_metadata is how you find out what a transfer would cost, and the client libraries or the API are how you actually move the bytes.

Reading the download history

list_downloads is a bounded window - at most 200 attempts, newest first - and it lists refusals alongside successes, because a denial and its http_status are what answer "it stopped working". A database missing from the answer means it is not in that window, never that it was never fetched.

Other Libraries

There are official InternetData client libraries available for many languages including PHP, Python, Go, Java, Ruby, and many popular frameworks such as Django, Rails, and Laravel. See our GitHub at https://github.com/internetdata for more.

About InternetData

IP intelligence databases: VPN, proxy, hosting, CDN and relay address space, provider catalogs and network metadata, published as CSV and MMDB.

License

This project is licensed under the MIT License.

Available Tools

4 tools
database_checksumGet a database's checksumsA
Read-onlyIdempotent

The published digests for one database file, for verifying a copy you already hold or deciding whether a build has changed since you last fetched it. It is licensed like the download itself, so a database this key cannot download is refused here too. Looking up a checksum is not a download and does not appear in list_downloads.

ParametersJSON Schema
NameRequiredDescriptionDefault
formatYesWhich published file to digest.
dataset_idYesA VERSIONED database id, from `versions[].id` in `list_databases` - `bogon_ip_v1`, not `bogon_ip`. The unversioned base id is a license reference and is not accepted here.

Output Schema

ParametersJSON Schema
NameRequiredDescription
checksumsYes

TDQS

A3.9/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already cover the read-only/idempotent safety profile, so the bar is lower. The description adds genuine behavioral context beyond them: the licensing gate (refused when the key cannot download the database) and the non-recording behavior (does not appear in list_downloads). It stops short of describing error specifics or rate limits.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Three tight, non-redundant sentences with no filler. The core purpose is stated first and the qualifying behaviors follow. Marginally docked because the opening is a noun phrase rather than leading with an action verb.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With an output schema present, the description need not explain return values, and with full param coverage plus annotations the safety story is covered. The description adds the licensing and non-recording caveats an agent would need; behavior around errors is left implicit but not essential.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the schema already documents both parameters in detail (versioned vs unversioned dataset_id, format enum). The description adds essentially no parameter-level meaning beyond 'one database file', so the baseline 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description specifies what is returned ("the published digests for one database file") and implicitly bounds its scope by noting it is not a download. It is clear, but the noun-phrase framing lacks an explicit verb and it does not directly contrast with sibling tools like database_metadata or list_databases.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives concrete use cases: verifying a copy you already hold or deciding whether a build has changed since you last fetched it. It also states an entitlement condition (a database the key cannot download is refused here too) and clarifies it does not surface in list_downloads. It stops short of naming an explicit alternative tool for comparison.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

database_metadataDescribe a databaseA
Read-onlyIdempotent

What is inside one database before you fetch it: the columns in each published format with their types, a few sample rows, the row count, the build date and the file sizes. Use this to answer questions about what a database contains without downloading it - the files reach several GB - and to budget a transfer before starting one.

ParametersJSON Schema
NameRequiredDescriptionDefault
dataset_idYesA VERSIONED database id, from `versions[].id` in `list_databases` - `bogon_ip_v1`, not `bogon_ip`. The unversioned base id is a license reference and is not accepted here.

Output Schema

ParametersJSON Schema
NameRequiredDescription
idYes
sizeYesBytes per format.
sampleNoA few real rows, keyed by format.
schemaYesColumns, keyed by format.
entriesYesRow count in the current build.
updatedYesISO-8601 date (YYYY-MM-DD) the published build was generated on.
sample_sizeNoBytes per format of the evaluation sample, where one is published.
update_freqNoHow often a new build is published.
sample_entriesNoRow count in the evaluation sample.

TDQS

A3.9/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint, idempotentHint, and openWorldHint, so the safety profile is covered. The description adds genuinely new behavioral context the annotations do not: the files reach several GB, making this a cheap pre-flight check, and it clarifies this is a metadata-only read useful for sizing or transfer planning.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences, front-loaded with the returned contents and followed by use cases; no filler, though the phrasing is slightly dense. It is appropriately sized for the information conveyed.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

An output schema exists, so return values need no prose explanation, and the description still usefully frames what those returns mean and why to call it. It is complete for the tool's purpose, with the only gap being no explicit contrast against sibling inspection tools.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, and the schema itself carries a detailed note about the versioned vs unversioned dataset_id. The description adds nothing about parameters, so the baseline 3 applies; the schema does the heavy lifting.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific verb-equivalent (describe/inspect) and enumerates the exact contents returned (columns per format with types, sample rows, row count, build date, file sizes), so an agent knows precisely what this yields. It implicitly contrasts with downloading ('without downloading it'), but never names the sibling tools list_databases or database_checksum, so sibling differentiation is only partial.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicit when-to-use guidance is given: to answer content questions without downloading, and to budget a transfer before starting one. It does not, however, name any alternative tool or state when to prefer database_checksum or list_databases instead, so the routing guidance stays contextual rather than complete.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

list_databasesList databasesA
Read-onlyIdempotent

The IP database catalog as this API key's organization may see it, one entry per database FAMILY, with standing saying where their license stands: licensed if the family is theirs today, expired if the term has ended, unlicensed if it is published but has never been bought. Each entry has a base id, which is what a license names, and a versions array whose id is what the other tools take - pass versions[].id (bogon_ip_v1), never the base (bogon_ip). Ask again rather than holding on to this: it is answered per key and is not the same for everyone.

ParametersJSON Schema
NameRequiredDescriptionDefault

No parameters

Output Schema

ParametersJSON Schema
NameRequiredDescription
databasesYes

TDQS

A4.7/5.0
Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations cover the safety profile (readOnly, idempotent, openWorld), so the bar is lower, and the description still adds material behavior: the result is answered per key, is not the same for everyone, and should be re-fetched rather than cached. It also defines the `standing` states precisely, which no annotation conveys.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Dense but front-loaded: the catalog purpose comes first, then the standing vocabulary, then the id-vs-base warning, then the caching caveat. Every sentence carries an actionable fact with no filler.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

An output schema exists so return values need not be restated, yet the description goes further by naming the key fields agents must act on and how to consume them. Combined with the per-key/caching caveat, nothing an agent needs to call and use this tool correctly is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Zero parameters, so per the rubric the baseline is 4; there is no parameter semantics to explain. The description instead spends its space on output identifiers (`base` vs `versions[].id`), which is useful but not param-related.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource (the IP database catalog) and immediately scopes it as 'as this API key's organization may see it, one entry per database FAMILY', which is far more precise than the title. It distinguishes itself from siblings like database_metadata by framing this as the catalog that yields the ids other tools consume.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It gives strong routing guidance - pass `versions[].id`, never `base`, to the other tools - and implies when to use it (to discover licensing/standing before calling a data tool). It does not explicitly contrast itself with database_metadata or list_downloads, so it stops short of full when/when-not guidance.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

list_downloadsList recent download attemptsA
Read-only

This organization's own recent download attempts, newest first, REFUSALS INCLUDED - a denial carries the outcome and http_status that answer "it stopped working", which nothing else here can. Use it to explain a failing fetch, to confirm a transfer ran, or to check whether a request was theirs. This is a bounded WINDOW of at most 200 rows, so a database missing from the answer means it is not in this window - never that it was never downloaded.

ParametersJSON Schema
NameRequiredDescriptionDefault
limitNoHow many attempts to return, newest first. At most 200; the API defaults to 50.

Output Schema

ParametersJSON Schema
NameRequiredDescription
downloadsYes

TDQS

A4.4/5.0
Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Goes well beyond the annotations: refusals are included, denials carry `outcome` and `http_status`, the result is bounded to at most 200 rows, and it warns that absence means 'not in this window' rather than 'never downloaded.' That last point is the kind of interpretation guard an agent cannot infer from readOnlyHint/openWorldHint.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loaded with the resource and the key differentiator, and every sentence adds information. The ALL-CAPS emphasis ('REFUSALS INCLUDED', 'WINDOW') is slightly loud but functionally marks the two facts that most affect interpretation.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

An output schema exists, so return values need no explanation; the description instead supplies what the schema cannot - refusal inclusion, the row cap, and the correct reading of a missing database. Complete for a bounded read-only list tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% and the `limit` parameter already documents the max of 200 and the API default of 50, so the schema carries the burden. The description adds the window framing but no syntax or format detail beyond it, making the baseline 3 appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource ('List recent download attempts'), scopes it ('this organization's own'), gives ordering ('newest first'), and explicitly carves out what no sibling can do ('answer "it stopped working", which nothing else here can'). An agent can distinguish it from list_databases without opening a schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives three concrete use cases: explain a failing fetch, confirm a transfer ran, check whether a request was theirs. Strong positive routing, but no explicit when-not-to-use and no named alternative tool for other download questions.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

  1. 4 tool updatesv2.2.0
    • Changeddatabase_checksum1 field changed
      • changedInput schema / properties / dataset_id / description
        Previous value: -"A VERSIONED database id, from `versions[].id` in `list_databases` - `bogon_ip_v1`, not `bogon_ip`. The unversioned base id is a licence reference and is not accepted here."New value: +"A VERSIONED database id, from `versions[].id` in `list_databases` - `bogon_ip_v1`, not `bogon_ip`. The unversioned base id is a license reference and is not accepted here."
    • Changeddatabase_metadata3 fields changed
      • changedInput schema / properties / dataset_id / description
        Previous value: -"A VERSIONED database id, from `versions[].id` in `list_databases` - `bogon_ip_v1`, not `bogon_ip`. The unversioned base id is a licence reference and is not accepted here."New value: +"A VERSIONED database id, from `versions[].id` in `list_databases` - `bogon_ip_v1`, not `bogon_ip`. The unversioned base id is a license reference and is not accepted here."
      • addedOutput schema / properties / sample_entries
        Added value: +{
+  "description": "Row count in the evaluation sample.",
+  "type": "integer"
+}
      • addedOutput schema / properties / sample_size
        Added value: +{
+  "additionalProperties": {
+    "format": "int64",
+    "type": "integer"
+  },
+  "description": "Bytes per format of the evaluation sample, where one is published.",
+  "type": "object"
+}
    • Changedlist_databases18 fields changed
      • changedOutput schema / properties / databases / items / description
        Previous value: -"One database FAMILY, with your organization's licence beside it. A\nlicence covers the family, while a download names a specific version,\nso the ids passed to `download` and `checksum` come from `versions`.\n"New value: +"One database FAMILY, with your organization's license beside it. A\nlicense covers the family, while a download names a specific version,\nso the ids passed to `download` and `checksum` come from `versions`.\n"
      • changedOutput schema / properties / databases / items / properties / base / description
        Previous value: -"The family, e.g. `vpn_ip`. What a licence is held against."New value: +"The family, e.g. `vpn_ip`. What a license is held against."
      • changedOutput schema / properties / databases / items / properties / expires / description
        Previous value: -"A hard stop. Null when the licence has no end date, which is the normal case for a rolling agreement, and when there is no licence. A rolling licence reports its turnover date in renews_at instead."New value: +"A hard stop. Null when the license has no end date, which is the normal case for a rolling agreement, and when there is no license. A rolling license reports its turnover date in renews_at instead."
      • removedOutput schema / properties / databases / items / properties / expires / nullable
        Removed value: -true
      • changedOutput schema / properties / databases / items / properties / expires / type
        Previous value: -"string"New value: +[
+  "string",
+  "null"
+]
      • changedOutput schema / properties / databases / items / properties / license_type / description
        Previous value: -"What your licence permits you to do with the data. Null when there\nis no licence.\n"New value: +"What your license permits you to do with the data. Null when there\nis no license, which is every family with standing `unlicensed`.\n"
      • removedOutput schema / properties / databases / items / properties / license_type / nullable
        Removed value: -true
      • changedOutput schema / properties / databases / items / properties / license_type / type
        Previous value: -"string"New value: +[
+  "string",
+  "null"
+]
      • removedOutput schema / properties / databases / items / properties / notice_due_at / nullable
        Removed value: -true
      • changedOutput schema / properties / databases / items / properties / notice_due_at / type
        Previous value: -"string"New value: +[
+  "string",
+  "null"
+]
      • changedOutput schema / properties / databases / items / properties / renews_at / description
        Previous value: -"When a rolling licence next renews. Null when the licence has no defined term, when expires sets a hard stop instead, and when there is no licence."New value: +"When a rolling license next renews. Null when the license has no defined term, when expires sets a hard stop instead, and when there is no license."
      • removedOutput schema / properties / databases / items / properties / renews_at / nullable
        Removed value: -true
      • changedOutput schema / properties / databases / items / properties / renews_at / type
        Previous value: -"string"New value: +[
+  "string",
+  "null"
+]
      • changedOutput schema / properties / databases / items / properties / standing / description
        Previous value: -"`licensed` is a live grant, `expired` one whose term has ended, and\n`unlicensed` a database published but never bought.\n"New value: +"Where your license for a database family stands today. `licensed` is a\nlive grant, `expired` one whose term has ended, and `unlicensed` a\ndatabase published but never bought.\n"
      • removedOutput schema / properties / databases / items / properties / starts / nullable
        Removed value: -true
      • changedOutput schema / properties / databases / items / properties / starts / type
        Previous value: -"string"New value: +[
+  "string",
+  "null"
+]
      • addedOutput schema / properties / databases / items / properties / versions / items / properties / formats / items / description
        Added value: +"A file format a database version is published in."
      • addedOutput schema / properties / databases / items / properties / versions / items / properties / sample_formats
        Added value: +{
+  "description": "The formats an evaluation sample is published in, if any.",
+  "items": {
+    "description": "A file format a database version is published in.",
+    "enum": [
+      "csvgz",
+      "mmdb"
+    ],
+    "type": "string"
+  },
+  "type": "array"
+}
    • Changedlist_downloads12 fields changed
      • removedOutput schema / properties / downloads / items / properties / apikey_id / nullable
        Removed value: -true
      • changedOutput schema / properties / downloads / items / properties / apikey_id / type
        Previous value: -"string"New value: +[
+  "string",
+  "null"
+]
      • removedOutput schema / properties / downloads / items / properties / bytes / nullable
        Removed value: -true
      • changedOutput schema / properties / downloads / items / properties / bytes / type
        Previous value: -"integer"New value: +[
+  "integer",
+  "null"
+]
      • removedOutput schema / properties / downloads / items / properties / client_ip / nullable
        Removed value: -true
      • changedOutput schema / properties / downloads / items / properties / client_ip / type
        Previous value: -"string"New value: +[
+  "string",
+  "null"
+]
      • removedOutput schema / properties / downloads / items / properties / http_status / nullable
        Removed value: -true
      • changedOutput schema / properties / downloads / items / properties / http_status / type
        Previous value: -"integer"New value: +[
+  "integer",
+  "null"
+]
      • addedOutput schema / properties / downloads / items / properties / sample
        Added value: +{
+  "description": "The evaluation sample rather than the database itself.",
+  "type": "boolean"
+}
      • removedOutput schema / properties / downloads / items / properties / user_agent / nullable
        Removed value: -true
      • changedOutput schema / properties / downloads / items / properties / user_agent / type
        Previous value: -"string"New value: +[
+  "string",
+  "null"
+]
      • changedOutput schema / properties / downloads / items / required
        Previous value: -[
-  "dataset_id",
-  "format",
-  "outcome",
-  "bytes",
-  "http_status",
-  "apikey_id",
-  "client_ip",
-  "user_agent",
-  "created"
-]New value: +[
+  "dataset_id",
+  "format",
+  "outcome",
+  "sample",
+  "bytes",
+  "http_status",
+  "apikey_id",
+  "client_ip",
+  "user_agent",
+  "created"
+]
  2. 4 tool updatesv1.0.0
    • First observeddatabase_checksum
    • First observeddatabase_metadata
    • First observedlist_databases
    • First observedlist_downloads
Deploy Server
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

TDQS

A3.9/5.0

Scored across 4 tools

Disambiguation5/5

Each tool targets a clearly distinct concern: catalog listing (list_databases), content inspection (database_metadata), integrity digests (database_checksum), and download history (list_downloads). The descriptions explicitly delimit boundaries, e.g. checksum lookups not appearing in list_downloads, leaving no realistic misselection risk.

Naming Consistency3/5

Two tools follow a list_<noun> verb pattern (list_databases, list_downloads) while the other two use a noun_noun form (database_metadata, database_checksum). The naming is readable and grouped sensibly but does not follow a single predictable convention.

Tool Count4/5

Four tools for a database catalog/verification service is on the lean side but each earns its place with a distinct role. It is slightly under-scoped for a data-delivery domain, but not thin enough to be a token surface.

Completeness2/5

The service frames itself around fetching large database files (licensing, checksums, download history), yet there is no tool to actually download or fetch a database, which is the core operation. Catalog, metadata, checksum, and history are covered, but the terminal action is missing, creating a dead end for the primary workflow.

Maintenance

ActivityMaintained
ResponsivenessNo issues

Resources

Related MCP Connectors

Related MCP Servers

  • SQL MCP Server

    apoorva183
    F
    license
    Not graded
    quality
    D
    maintenance
    Exposes a SQLite database to AI assistants with structured, read-safe access. Includes five tools for schema exploration, querying, and sampling data.
    -

  • db-mcp

    chud-lori
    F
    license
    Not graded
    quality
    C
    maintenance
    Provides read-only database access for AI agents across multiple databases (Postgres, MySQL, MongoDB, Elasticsearch) with enforced read-only guarantees and separate tools for prod and non-prod environments.
    -

  • Local Data Engineering MCP

    andrebarrocas
    F
    license
    Not graded
    quality
    C
    maintenance
    Enables AI agents to inspect a mock data platform locally via SQLite, using read-only tools for schemas, row counts, freshness, queries, and pipeline status without cloud credentials.
    -

  • DB MCP Demo

    azizdevfull
    F
    license
    Not graded
    quality
    B
    maintenance
    Provides read-only database access for AI agents, enabling table listing, schema inspection, and filtered row queries through MCP tools.
    -