Skip to main content
Glama
increff-jatin-gupta

webget-mcp

by increff-jatin-gupta
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

webget-mcp

An MCP (Model Context Protocol) server that lets an MCP client (e.g. Claude Desktop) run read-only SQL queries against Increff Webget's database replicas, by reusing an authenticated browser session instead of requiring separate DB credentials.

Tools

  • webget_list_databases — lists the database server names available in Webget's SQL Query Editor (the same dropdown as https://saas.increff.com/webget/in/sql). Uses a bundled snapshot by default; pass refresh: true to re-scrape the live dropdown (needed right after a fresh install, since the bundled snapshot starts empty, or to pick up newly added servers).

  • webget_run_query — runs a single read-only SQL statement (SELECT, SHOW, EXPLAIN, DESCRIBE) against a given database server and returns the result as rows/columns. Statements containing write/DDL keywords (INSERT, UPDATE, DELETE, DROP, ALTER, TRUNCATE, CREATE, GRANT, REVOKE, REPLACE, MERGE) are rejected before they ever reach webget.

Query confirmation

Every query is shown to a human and requires explicit approval before it runs. The server tries MCP elicitation first (an in-chat confirmation prompt); if the connected client doesn't support that method, it falls back to a native macOS confirmation dialog (osascript display dialog) shown directly on the machine running the server. This is enforced server-side on every single call and does not depend on — and cannot be bypassed by — any client-side "always allow" setting.

Related MCP server: FastAPI Database MCP Server

Requirements

  • Node.js 20+ (an old node picked up from PATH, e.g. via a stale nvm shim, will fail to run the built ES2022/top-level-await output — point your MCP client config at an absolute path to a Node 20+ binary)

  • macOS (the confirmation-dialog fallback shells out to osascript)

  • A Webget/Increff SSO account

Setup

npm install
npm run build

One-time login

npm run login

This opens a real, visible Chromium window pointed at webget. Complete your company SSO login there. The session is saved to a local persistent browser profile at ~/.webget-mcp/ and reused by the MCP server for all future queries — you should only need to do this again after your session expires.

If the automated login gets blocked by bot detection, you can instead import an already-logged-in session's cookies directly from Chrome DevTools:

# DevTools -> Network tab -> pick a request to the target domain -> Headers
# -> Request Headers -> copy the full "cookie:" value
node dist/import-cookies.js saas.increff.com "<cookie header value>"
node dist/import-cookies.js account.increff.com "<cookie header value>"

Run once per domain; each run merges into the same stored session state.

Connect it to your MCP client

For Claude Desktop, add to claude_desktop_config.json:

{
  "mcpServers": {
    "webget": {
      "command": "/absolute/path/to/node",
      "args": ["/absolute/path/to/webget-mcp/dist/index.js"]
    }
  }
}

Use an absolute path for both command and args — Claude Desktop's default PATH resolution can pick up an unexpected Node version, and relative paths won't resolve correctly. After editing the config, fully quit and reopen Claude Desktop (a running instance can silently overwrite external edits to this file with its own in-memory copy).

Notes

  • Session/login state lives outside the repo at ~/.webget-mcp/ — it is never part of this project and should never be committed.

  • Results are limited only by webget's own API limits (roughly 1 MB / 10,000 rows per request). For larger exports, page through with ORDER BY <key> LIMIT n OFFSET m across multiple calls.

  • Only read-only statements are accepted; there is no way to run write or schema-changing SQL through this server.

Available Tools

2 tools
webget_list_databasesList webget database serversA
Read-onlyIdempotent

Lists the database server names available in Increff Webget's SQL Query Editor (the same dropdown as https://saas.increff.com/webget/in/sql). Use the returned name as the database argument to webget_run_query. Set refresh: true to re-scrape the live list instead of using the bundled snapshot (slower, but catches newly added servers, and is necessary right after a fresh install since the bundled snapshot starts empty).

ParametersJSON Schema
NameRequiredDescriptionDefault
filterNoCase-insensitive substring to filter database names by, e.g. a client/brand name.
refreshNoIf true, re-scrape the live dropdown from webget instead of using the bundled snapshot.

TDQS

A4.7/5.0
Behavior5/5

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

Beyond the readOnlyHint, openWorldHint, and idempotentHint annotations, the description discloses the snapshot-vs-live behavior: it normally uses a bundled snapshot, refresh re-scrapes the live list and is slower, and the snapshot starts empty after fresh install. This meaningfully clarifies observable behavior without contradicting the annotations.

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?

Three sentences, each earning its place: the first states what the tool lists, the second connects the output to the sibling tool, and the third explains the refresh behavior with its practical caveat. Information is front-loaded and nothing is redundant.

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?

For a read-only listing tool with two optional parameters and no output schema, the description is complete: it conveys the return value (database server names), how to use that return value downstream, and the full semantics of the refresh parameter. No critical calling detail 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?

Schema coverage is 100%, so the baseline is 3, but the description adds real value by explaining the refresh parameter's tradeoffs and necessity, and by showing how the returned name maps to the database argument of webget_run_query. The filter parameter is left to the schema, which already documents it clearly.

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?

The description states a specific verb and resource: it lists database server names available in Increff Webget's SQL Query Editor, tied to a concrete URL dropdown. It also distinguishes its role from the sibling webget_run_query by explaining that its output feeds the database argument to that tool.

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 clear context: the tool is the way to discover server names before calling webget_run_query. It also provides conditional guidance for refresh, explaining when the live re-scrape is necessary (after fresh install, to catch new servers), though it does not explicitly state exclusions or alternative list tools.

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

webget_run_queryRun a read-only SQL query via webgetA
Read-only

Executes a read-only SQL query against a webget database server (a read-replica MySQL DB, per company policy) and returns the result as rows/columns. Only SELECT-style statements are allowed; use webget_list_databases first to find the exact database name. Requires a prior login (run npm run login in the webget-mcp project once) and inherits webget's own row/size/time limits. Before running, the human is always shown the exact query and must explicitly allow it — this is enforced by the server itself and cannot be bypassed by an "always allow" client setting.

ParametersJSON Schema
NameRequiredDescriptionDefault
queryYesA single read-only SQL statement (SELECT / SHOW / EXPLAIN / DESCRIBE).
databaseYesExact database server name, e.g. "db.saas.increff.com". See webget_list_databases.

TDQS

A4.7/5.0
Behavior5/5

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

Annotations (readOnlyHint=true, destructiveHint=false) already establish the read-only safety profile; the description adds valuable context beyond that: the mandatory prior login, inherited row/size/time limits, and the enforced human approval step that cannot be bypassed. No contradiction exists; the description enriches behavioral understanding.

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?

The description is multi-sentence but every clause carries weight: purpose, constraints, prerequisites, approval flow. It is front-loaded with the core action and then elaborates. No filler, though slightly longer than strictly necessary, which is justified given the safety-critical approval aspect.

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?

There is no output schema, so the description must cover return values; it states 'returns the result as rows/columns' which is minimal but acceptable. It also covers authentication, limits, and the human-approval mechanism. It does not detail error handling or result formatting nuances, but for a read-only query tool with these constraints, it is largely complete.

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?

Schema coverage is 100% (both parameters are described), so the baseline is 3. The description adds extra guidance by explaining the database parameter must come from webget_list_databases and clarifying the query constraint to 'SELECT-style statements only', which goes beyond the schema's generic wording and aids correct invocation.

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 ('executes'), resource (read-only SQL query on webget database server), and scope (read-only, SELECT-style). It also names the sibling tool (webget_list_databases) and distinguishes by instructing to use that first, so an agent can clearly tell them apart.

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

Usage Guidelines5/5

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

Explicitly instructs to run webget_list_databases first to find the exact database name, and states prerequisites (npm run login) and limitations (row/size/time limits). It also clearly conveys that only SELECT-style statements are allowed, implicitly routing the agent away from write operations. No ambiguity remains about when to use this tool versus the alternative.

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. 2 tool updatesv1.0.0
    • First observedwebget_list_databases
    • First observedwebget_run_query
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

A4.5/5.0

Scored across 2 tools

Disambiguation5/5

The two tools serve clearly distinct purposes: one lists available databases, the other executes queries against them. There is a clear dependency and no overlap in functionality.

Naming Consistency4/5

Both tools follow the `webget_` prefix and use verb_noun style: `list_databases` and `run_query`. Minor deviation: `list_databases` uses a plural noun while `run_query` uses a singular noun, but the pattern is consistent and predictable.

Tool Count3/5

With only two tools, the set is minimal but appropriate for a focused purpose: listing databases and running queries. It feels slightly thin but is sufficient for the core functionality without unnecessary bloat.

Completeness4/5

The surface covers the primary workflows: discovering databases and executing read-only queries. Minor gaps exist such as no tool to inspect schema or query metadata, but these are not strictly necessary for the stated purpose.

Maintenance

ActivityMaintained
ResponsivenessNo issues

Resources

Related MCP Connectors

Related MCP Servers

  • mcp-read-only-sql

    lukleh
    A
    license
    Not graded
    quality
    C
    maintenance
    Provides secure read-only SQL access to PostgreSQL and ClickHouse databases with built-in safety features like read-only enforcement, timeouts, and managed result files.
    MIT

  • FastAPI Database MCP Server

    amararun
    F
    license
    Not graded
    quality
    F
    maintenance
    Provides read-only SQL query access to Postgres and DuckDB databases via MCP tools, with extensive security hardening for public endpoints.
    1
    -

  • Text-to-SQL MCP Server

    down530
    F
    license
    Not graded
    quality
    C
    maintenance
    Enables secure SQL query execution on MySQL databases with authentication and permission control, allowing users to explore database tables and run read-only queries.
    -

  • DuckDB MCP Server

    poovenp
    F
    license
    Not graded
    quality
    C
    maintenance
    Enables running read-only SQL queries and exploring DuckDB databases through MCP tools like listing tables, describing schemas, and fetching paginated data.
    -