Agentic access

ThynkQ MCP Server

Name: ThynkQ MCP Server
Author: ThynkQ

A small, read-only Model Context Protocol server. It exists because ThynkQ's own product is MCP security tooling and its service line includes AI integration. This is a live, testable demonstration of that competency, not a marketing gimmick bolted onto an unrelated company.

$ npx mcp-scanCaptured with CLI v2.1.0 on 2026-10-10

CRITICAL exposed-secret

Exposed GitHub Token in environment variable 'WEATHER_TOKEN'.

↳ Move the secret to a secure environment variable and reference it instead (e.g., ${WEATHER_TOKEN}).

MEDIUM unverified-source

Server 'weather-demo-server' is an unscoped package from an unverified source (typosquatting risk).

↳ Verify the publisher of 'weather-demo-server' on npmjs.com before trusting this server, or ask the maintainer to publish with npm provenance (npm publish --provenance from GitHub Actions or GitLab CI) so mcp-scan can confirm it automatically.

Scanned 1 server across 1 client in 494ms

1 critical 0 high 1 medium 0 low

by Rodolf · thynkQ thynkq.com

Captured from a purpose-built synthetic MCP configuration. It does not inspect this page or your machine.

Tools

get_services
List ThynkQ engagement lanes (Build Readiness Audit, Rescue Sprint, Launch Build, Product Build, Engineering Retainer), the MCP Risk Review, and ThynkQ Care with its fixed-price fixes, with scope, fit guidance, and URLs. Read-only.
get_pricing
List current prices and durations for every ThynkQ engagement lane, the MCP Risk Review, ThynkQ Care, and the fixed-price fixes. Read-only. Does not report availability or capacity, which changes week to week.
get_case_studies
List published ThynkQ case studies with client, timeline, problem, intervention, and outcome. Read-only.

It is read-only, by design

Three tools, all read: get_services, get_pricing, get_case_studies. There are no write tools, no lead capture, and no authentication. Nothing to configure, nothing that touches your data. Every tool reads from the same data modules that render the live /services and /pricing pages, so a tool response cannot say something the website itself does not also say. It also does not report current availability or capacity: that changes week to week, and a stale "we have room" claim in a cached response is worse than no claim at all.

Endpoint

POST https://thynkq.com/api/mcp: JSON-RPC 2.0 over HTTP, following the MCP Streamable HTTP transport. This server answers every request synchronously with a single JSON object (the transport spec allows this as an alternative to opening a Server-Sent Events stream). It does not open an SSE stream, since none of its tools need to push messages to a client. GET on the endpoint returns 405 for the same reason. There is no session negotiation: every request is answered independently from static data.

Try it

POSThttps://thynkq.com/api/mcp

List the available tools:

curl -sX POST https://thynkq.com/api/mcp \
  -H "Content-Type: application/json" \
  -d '{"jsonrpc":"2.0","id":1,"method":"tools/list"}'

Call a tool:

curl -sX POST https://thynkq.com/api/mcp \
  -H "Content-Type: application/json" \
  -d '{"jsonrpc":"2.0","id":2,"method":"tools/call","params":{"name":"get_pricing"}}'

What is verified vs. not

The JSON-RPC message shapes and the Streamable HTTP transport behavior above (POST as the single required method, 202 for notifications, 200 with a JSON body or an SSE stream for requests, 405 on GET when no server-push capability exists) were checked against the official MCP specification. What is not independently verified: whether every MCP client implementation in the wild tolerates a server that never opens an SSE stream, and whether every client requires a session ID this server does not issue. If a client you use fails to connect, that is the most likely reason. Let us know.