Remote MCP

Feinian WebSql MCP

Read-only MCP access to controlled multi-provider query execution, target visibility, and query audit inspection. Database names are unique within a project, and every query resolves targets by project plus database name.

Endpoints

MCP transporthttps://websql.feinian.net/mcp
Human docshttps://websql.feinian.net/docs/mcp
Machine manifesthttps://websql.feinian.net/docs/mcp/server.json

Authentication

Send Authorization: Bearer <QueryApi.ServiceToken> on MCP requests. The MCP endpoint reuses the same bearer token as the existing POST /query API.

Browser origin policy

Requests without an Origin header are allowed. If an Origin header is present, it must match one of the configured Mcp:AllowedOrigins values.

No browser origins are currently configured. Requests that send an Origin header will be rejected until Mcp:AllowedOrigins is populated.

Tools

  • list_projects: list configured project contexts and their target counts.
  • get_project_context: inspect one project's note and member databases; database names are unique within this project.
  • list_databases: list configured target data sources without exposing connection strings. Names may repeat across projects.
  • query_data_source: run a single safe provider-specific read-only request with required project and return rows, meta, and auditId.
  • query_project: run ordered multi-step project queries and return per-step results, auditIds, and one orchestrationId.
  • list_query_audits: browse recent success, failure, and rejection audit records.
  • get_query_audit: fetch the full detail for one audit entry by ID.

Resources

  • websql://policy/query-safety: the enforced provider safety and execution limit policy.
  • websql://projects/catalog: current project catalog in JSON form.
  • websql://projects/{project}/context: one project context with database membership.
  • websql://databases/catalog: current target database catalog in JSON form.

Client Config Example

The exact file shape depends on your MCP host, but a generic remote-server entry typically looks like this:

{
  "servers": {
    "websql": {
      "type": "remote",
      "url": "https://websql.feinian.net/mcp",
      "headers": {
        "Authorization": "Bearer <QueryApi.ServiceToken>"
      }
    }
  }
}

query_data_source input example

The project field is required. The same database name can exist in multiple projects.

{
  "project": "payments-core",
  "database": "reporting",
  "provider": "postgresql",
  "operation": "sql",
  "payload": {
    "text": "select * from user_provider_supply_binding where user_id = @userId and lower(provider_name) = 'openai'",
    "params": {
      "userId": 123
    },
    "queryCategory": "data"
  }
}

server.json Preview

This same payload is available at https://websql.feinian.net/docs/mcp/server.json.

{
  "$schema": "https://static.modelcontextprotocol.io/schemas/2025-12-11/server.schema.json",
  "name": "abc.red/websql",
  "title": "Feinian WebSql",
  "description": "Remote read-only MCP access to WebSql multi-provider query execution, target catalog, and query audit data.",
  "version": "1.0.0\u002Bfe1ec3aff8a3a78a1002935e2866c896621c6435",
  "remotes": [
    {
      "type": "streamable-http",
      "url": "https://websql.feinian.net/mcp",
      "headers": [
        {
          "name": "Authorization",
          "description": "Required. Use the format: Bearer \u003CQueryApi.ServiceToken\u003E.",
          "isRequired": true,
          "isSecret": true
        }
      ]
    }
  ]
}

Safety Policy

# WebSql Query Safety Policy

WebSql enforces the following rules for MCP and `/query` requests:

- Every single-database request must specify `project`, `database`, `provider`, `operation`, and a provider-specific `payload`.
- Project orchestration requests must specify a `project` plus one or more sequential `steps`.
- Query execution always targets a named data source that has been pre-configured in WebSql.
- Target database names are unique within a project, not globally; WebSql resolves targets by `project + database`.
- Disabled target databases cannot be queried.
- WebSql verifies that every referenced database belongs to the specified project.
- Queries are audited whether they succeed, fail, or are rejected by validation.

Provider rules:

- `postgresql/sql`: only a single read-only `SELECT` or `WITH ... SELECT` statement is allowed, with the same `queryCategory` controls as the HTTP API.
- `mongodb/find`: `collection`, `filter`, `projection`, `sort`, `skip`, and `limit` are accepted. `filterJson`, `projectionJson`, and `sortJson` are also accepted as Mongo Extended JSON strings; do not provide both object and string forms for the same field.
- `mongodb/aggregate`: only read-only pipeline stages are allowed. `$out`, `$merge`, `$function`, and `$accumulator` are rejected.
- `redis`: only the explicit read-only operations `get`, `mget`, `hget`, `hmget`, `lrange`, `smembers`, and `zrange` are allowed.

Execution limits:

- System default timeout: `30` seconds
- System default max rows: `500`
- System hard max rows: `2000`
- A target database can enforce a smaller timeout or row limit than the system defaults.

Operational guidance:

- Prefer the smallest provider-specific payload that answers the question.
- Use `list_projects` and `get_project_context` to discover the right project-scoped PostgreSQL, MongoDB, and Redis targets for an investigation.
- Use `get_operation_schema` to inspect required payload fields, examples, and validation constraints.
- Use `introspect_data_source` for safe discovery: PostgreSQL schemas/tables/columns/indexes, MongoDB collections/indexes/sample keys, Redis key patterns and key summaries without values.
- Use `list_databases` to confirm the exact project and database name before calling `query_data_source`.
- Each successful `query_data_source` response includes an `auditId` that can be inspected later with `get_query_audit`.
- Each `query_project` step returns its own `auditId`, and all steps share an `orchestrationId`.
- A common project investigation flow is PostgreSQL summary/request id lookup, MongoDB detail document lookup, then Redis cache/runtime state inspection.