Every figure re-checked against SQL-computed facts; unsupported questions refused with the reason.
Maintain this server? Claim it
Call this server's tools from your browser. Nothing to install.
Requests go through mcptry because browsers can't call most MCP servers directly. Header values are sent to the server for that request only and are never stored or logged.
Tool list from our last check. Connect live to refresh it.
BYO step 1 of 2: run the server-side trust plane for a business question (plan, SQL-verified facts, evidence retrieval, answerability gate, prompt composition) and return the composed prompt plus a single-use prepare_key (a signed handoff token; echo it back VERBATIM and in full, or use the short ask_id alias; in prose always say the ask_id, never the token). Read-only: prepare holds no server state and is safe to run without confirmation — the receipt is minted only at ask_submit_draft. Pass the user's question VERBATIM: do not expand, narrow, or reword it — the server plans coverage itself, and an unrequested rewrite misleads the user about what was asked. If you must revise it (e.g. to fold in essential conversation context), you MUST also pass the user's exact wording in original_question so the panel can disclose the revision. YOU (the connected model) then write the draft answer from that prompt and submit it with ask_submit_draft — generation happens on your side, so no LLM credential ever reaches this server. An unanswerable question still receives a prompt for reference; its draft is force-refused at submit and can never earn a verified verdict. Only a policy refusal stops at prepare. Recommended drafting path on this deployment.
the business question to ground, in the USER'S OWN WORDS, verbatim; do not expand, narrow, or reword it — the server plans coverage itself. The server plans, computes SQL facts, retrieves evidence, gates answerability, and composes the prompt YOU should answer from
optional prior conversation turns (role user|assistant) to thread into the composed prompt for follow-up questions
REQUIRED IF question is not the user's exact wording: the user's original question, verbatim, so the panel can display your revision as a revision. Omit when question is verbatim
BYO step 1 of 2: run the server-side trust plane for a business question (plan, SQL-verified facts, evidence retrieval, answerability gate, prompt composition) and return the composed prompt plus a single-use prepare_key (a signed handoff token; echo it back VERBATIM and in full, or use the short ask_id alias; in prose always say the ask_id, never the token). Read-only: prepare holds no server state and is safe to run without confirmation — the receipt is minted only at ask_submit_draft. Pass the user's question VERBATIM: do not expand, narrow, or reword it — the server plans coverage itself, and an unrequested rewrite misleads the user about what was asked. If you must revise it (e.g. to fold in essential conversation context), you MUST also pass the user's exact wording in original_question so the panel can disclose the revision. YOU (the connected model) then write the draft answer from that prompt and submit it with ask_submit_draft — generation happens on your side, so no LLM credential ever reaches this server. An unanswerable question still receives a prompt for reference; its draft is force-refused at submit and can never earn a verified verdict. Only a policy refusal stops at prepare. Recommended drafting path on this deployment.
| Argument | Type | Description |
|---|---|---|
| history | null | array | optional prior conversation turns (role user|assistant) to thread into the composed prompt for follow-up questions |
| question* | string | the business question to ground, in the USER'S OWN WORDS, verbatim; do not expand, narrow, or reword it — the server plans coverage itself. The server plans, computes SQL facts, retrieves evidence, gates answerability, and composes the prompt YOU should answer from |
| original_question | string | REQUIRED IF question is not the user's exact wording: the user's original question, verbatim, so the panel can display your revision as a revision. Omit when question is verbatim |
{
"type": "object",
"required": [
"question"
],
"properties": {
"history": {
"type": [
"null",
"array"
],
"items": {
"type": "object",
"required": [
"role",
"content"
],
"properties": {
"role": {
"type": "string"
},
"content": {
"type": "string"
}
},
"additionalProperties": false
},
"description": "optional prior conversation turns (role user|assistant) to thread into the composed prompt for follow-up questions"
},
"question": {
"type": "string",
"description": "the business question to ground, in the USER'S OWN WORDS, verbatim; do not expand, narrow, or reword it — the server plans coverage itself. The server plans, computes SQL facts, retrieves evidence, gates answerability, and composes the prompt YOU should answer from"
},
"original_question": {
"type": "string",
"description": "REQUIRED IF question is not the user's exact wording: the user's original question, verbatim, so the panel can display your revision as a revision. Omit when question is verbatim"
}
},
"additionalProperties": false
}Fetch the published verdict for an ask_prepare session (status: pending, published, or unknown). This is the app panel's polling surface, so the verified answer renders inside the panel that prepared the question. As the connected model you normally never need it: write your draft and call ask_submit_draft. Exception: if you are asked to submit for a session whose composed prompt is no longer in your context, call this with include_prompt true to receive that session's exact prompt again, then draft and submit.
| Argument | Type | Description |
|---|---|---|
| prepare_key* | string | the session_id value returned by the prepare tool |
| include_prompt | boolean | set true to receive the pending session's composed prompt messages again, e.g. when the ask_prepare result is no longer in your context; the same caller already received this prompt at prepare time |
{
"type": "object",
"required": [
"prepare_key"
],
"properties": {
"prepare_key": {
"type": "string",
"description": "the session_id value returned by the prepare tool"
},
"include_prompt": {
"type": "boolean",
"description": "set true to receive the pending session's composed prompt messages again, e.g. when the ask_prepare result is no longer in your context; the same caller already received this prompt at prepare time"
}
},
"additionalProperties": false
}BYO step 2 of 2: verify the draft you wrote for an ask_prepare prompt. The server runs the SAME post-answer guards the strict path uses (facts presence, tagged claims, concept binding, earner-name grounding) against its own SQL facts and publishes the trust envelope; a draft that fails any guard is refused. Pass the prepare_key token back VERBATIM and in full. Handoffs are single-use per verdict and expire.
| Argument | Type | Description |
|---|---|---|
| model | string | optional: the model that wrote the draft, recorded in the trace |
| raw_answer | string | your COMPLETE raw draft answer to the composed prompt (including any structured answer/claims JSON the prompt's contract asked for). Omit ONLY when you are declining, in which case decline_reason is required |
| prepare_key* | string | the session_id value returned by the prepare tool |
| decline_reason | string | use INSTEAD of raw_answer when you are choosing not to submit a draft: state plainly why, in one or two sentences addressed to the user. The reason is shown to them in the panel, the handoff stays open for them to override, and nothing is verified or published |
{
"type": "object",
"required": [
"prepare_key"
],
"properties": {
"model": {
"type": "string",
"description": "optional: the model that wrote the draft, recorded in the trace"
},
"raw_answer": {
"type": "string",
"description": "your COMPLETE raw draft answer to the composed prompt (including any structured answer/claims JSON the prompt's contract asked for). Omit ONLY when you are declining, in which case decline_reason is required"
},
"prepare_key": {
"type": "string",
"description": "the session_id value returned by the prepare tool"
},
"decline_reason": {
"type": "string",
"description": "use INSTEAD of raw_answer when you are choosing not to submit a draft: state plainly why, in one or two sentences addressed to the user. The reason is shown to them in the panel, the handoff stays open for them to override, and nothing is verified or published"
}
},
"additionalProperties": false
}Compare two departments by headcount and compensation. NOTE: internal drafting is disabled on this deployment. If your client supports MCP sampling, this tool asks YOUR model to draft in the same call (verified server-side); otherwise it returns an explicit refusal, and you should use ask_prepare then ask_submit_draft to draft with your own model.
| Argument | Type | Description |
|---|---|---|
| a* | string | the first department |
| b* | string | the second department |
{
"type": "object",
"required": [
"a",
"b"
],
"properties": {
"a": {
"type": "string",
"description": "the first department"
},
"b": {
"type": "string",
"description": "the second department"
}
},
"additionalProperties": false
}Corroborate a figure you obtained (e.g. from run_sql) against the verified fact store: it re-derives the named value_key from the same SQL the verified pipeline uses and compares. AGREE lifts an otherwise-unverified session to 'corroborated'; DISAGREE marks a CONFLICT (worse than unverified). This is the only way a raw figure earns trust back, and it can only ever agree with a number the fact store itself computed. Resolvable keys cover the single-snapshot fact concepts plus temporal and per-department growth keys (e.g. indexed_people.<dept>); per-question keys (a named department's median, one person's direct-report count) return unmapped.
| Argument | Type | Description |
|---|---|---|
| value* | string | the figure you obtained (e.g. from run_sql) to corroborate against the verified fact store |
| value_key* | string | the claimable fact key naming the verified concept to re-derive, e.g. people, indexed_active_people, median_income_cents, or a per-department growth key like indexed_people.engineering (the keys a verified answer exposes as CLAIMABLE FACT KEYS) |
{
"type": "object",
"required": [
"value_key",
"value"
],
"properties": {
"value": {
"type": "string",
"description": "the figure you obtained (e.g. from run_sql) to corroborate against the verified fact store"
},
"value_key": {
"type": "string",
"description": "the claimable fact key naming the verified concept to re-derive, e.g. people, indexed_active_people, median_income_cents, or a per-department growth key like indexed_people.engineering (the keys a verified answer exposes as CLAIMABLE FACT KEYS)"
}
},
"additionalProperties": false
}List safe metadata for the registered fact queries available on the server-pinned dataset: IDs, labels, parameters, and result shapes, never SQL. Use this when a question appears relevant but a selected route produced no facts; a route miss is not evidence that the underlying records are absent.
No arguments.
{
"type": "object",
"additionalProperties": false
}Surface payroll and deduction anomalies in the latest snapshot. NOTE: internal drafting is disabled on this deployment. If your client supports MCP sampling, this tool asks YOUR model to draft in the same call (verified server-side); otherwise it returns an explicit refusal, and you should use ask_prepare then ask_submit_draft to draft with your own model.
No arguments.
{
"type": "object",
"additionalProperties": false
}Return the Art. 13 transparency descriptor: intended purpose, capabilities, limitations, human oversight, logging mechanism, and article mapping.
No arguments.
{
"type": "object",
"additionalProperties": false
}Show the SQL behind one answer you already received, addressed by its correlation_id. Returns only the recorded fact queries (id, version, label, SQL, parameters, result schema, dataset version) for that answer: no rows, no evidence text, no answer text, no envelope, and no way to list the catalog. Recorded SQL has its arguments inlined as literals, so a query that filters on a specific value discloses that value; the built-in workforce queries inline only snapshot ids. Requires the persisted compliance log and the same session that produced the answer. Absent from the no-auth public demo.
| Argument | Type | Description |
|---|---|---|
| correlation_id* | string | the correlation_id published on the answer whose queries you want to see; obtained from that answer, never guessed |
{
"type": "object",
"required": [
"correlation_id"
],
"properties": {
"correlation_id": {
"type": "string",
"description": "the correlation_id published on the answer whose queries you want to see; obtained from that answer, never guessed"
}
},
"additionalProperties": false
}Show ONE retrieved evidence document behind an answer you already received, addressed by that answer's correlation_id plus a document_id from its evidence_documents references. Returns the full stored document (title, body, metadata, embedding_text) with the retrieval rank and scores the answer recorded; never the raw embedding vector. Only documents the addressed answer actually recorded resolve: there is no fetch-by-id in general and no way to browse the store. Requires the persisted compliance log and the same session that produced the answer. Absent from the no-auth public demo.
| Argument | Type | Description |
|---|---|---|
| document_id* | integer | the document_id of one entry in that answer's evidence_documents references |
| correlation_id* | string | the correlation_id published on the answer whose evidence you want to inspect; obtained from that answer, never guessed |
{
"type": "object",
"required": [
"correlation_id",
"document_id"
],
"properties": {
"document_id": {
"type": "integer",
"description": "the document_id of one entry in that answer's evidence_documents references"
},
"correlation_id": {
"type": "string",
"description": "the correlation_id published on the answer whose evidence you want to inspect; obtained from that answer, never guessed"
}
},
"additionalProperties": false
}Return the management/reporting chain for an employee. NOTE: internal drafting is disabled on this deployment. If your client supports MCP sampling, this tool asks YOUR model to draft in the same call (verified server-side); otherwise it returns an explicit refusal, and you should use ask_prepare then ask_submit_draft to draft with your own model.
| Argument | Type | Description |
|---|---|---|
| employee* | string | the employee whose management chain to return |
{
"type": "object",
"required": [
"employee"
],
"properties": {
"employee": {
"type": "string",
"description": "the employee whose management chain to return"
}
},
"additionalProperties": false
}Execute a registered, versioned read-only fact query against the server-pinned dataset. Provide query_id and version only: SQL is approved by the domain pack, never caller-supplied. Returns normalized rows plus a reproducible trust receipt containing the dataset and query versions.
| Argument | Type | Description |
|---|---|---|
| version* | string | immutable registered query version |
| query_id* | string | registered fact-query id; SQL is resolved by the server and must not be supplied here |
| parameters | object | optional typed values for parameters declared by the registered query |
{
"type": "object",
"required": [
"query_id",
"version"
],
"properties": {
"version": {
"type": "string",
"description": "immutable registered query version"
},
"query_id": {
"type": "string",
"description": "registered fact-query id; SQL is resolved by the server and must not be supplied here"
},
"parameters": {
"type": "object",
"description": "optional typed values for parameters declared by the registered query",
"additionalProperties": true
}
},
"additionalProperties": false
}Run YOUR OWN JavaScript in the in-tenant coderunner sandbox with the read-only, snapshot-scoped plumb.query() SDK. No filesystem, environment, or general network access. Read plumbline://sandbox-api.d.ts before writing code. The raw-SQL server opt-in is enabled, but results still bypass the trust path and are UNVERIFIED. Returns stdout/stderr plus metadata-only host-call trace evidence.
| Argument | Type | Description |
|---|---|---|
| code* | string | JavaScript source to execute in the in-tenant coderunner sandbox. No filesystem, environment, or general network access. When the server explicitly enables raw SQL and uses the local grant-capable runner, a read-only snapshot-scoped SDK is preloaded as global 'plumb' and plumbline://sandbox-api.d.ts is listed; otherwise the sandbox is airtight and plumb is undefined. console.log output is returned as stdout. |
| concepts | null | array | optional: the fact concepts this code computes, as claimable fact keys (e.g. median_income_cents) or free-form names. The server reports per concept whether a registered seed exists (cross_check can corroborate figures) or not (cross_check will return unmapped: the verified store can never corroborate them). |
| acknowledge_unverified | boolean | set true to confirm you understand results BYPASS the trust plane and are UNVERIFIED, and that you will label them so to the user. On deployments with the acknowledgment gate the FIRST raw call of a session is refused without it; one acknowledgment covers the rest of the session. |
{
"type": "object",
"required": [
"code"
],
"properties": {
"code": {
"type": "string",
"description": "JavaScript source to execute in the in-tenant coderunner sandbox. No filesystem, environment, or general network access. When the server explicitly enables raw SQL and uses the local grant-capable runner, a read-only snapshot-scoped SDK is preloaded as global 'plumb' and plumbline://sandbox-api.d.ts is listed; otherwise the sandbox is airtight and plumb is undefined. console.log output is returned as stdout."
},
"concepts": {
"type": [
"null",
"array"
],
"items": {
"type": "string"
},
"description": "optional: the fact concepts this code computes, as claimable fact keys (e.g. median_income_cents) or free-form names. The server reports per concept whether a registered seed exists (cross_check can corroborate figures) or not (cross_check will return unmapped: the verified store can never corroborate them)."
},
"acknowledge_unverified": {
"type": "boolean",
"description": "set true to confirm you understand results BYPASS the trust plane and are UNVERIFIED, and that you will label them so to the user. On deployments with the acknowledgment gate the FIRST raw call of a session is refused without it; one acknowledgment covers the rest of the session."
}
},
"additionalProperties": false
}Run YOUR OWN single read-only SELECT/WITH over the virtual snapshot_* relations. The query is statically verified against an allowlist, rewritten to the active snapshot, and run read-only. This BYPASSES the planner, grounding gate, and answer-facts reconciliation, so results are UNVERIFIED and labelled as such. Deployments may refuse the FIRST raw call of a session pending acknowledge_unverified: true (the refusal says how to proceed). Optionally declare `concepts` to learn which figures the fact store could corroborate via cross_check.
| Argument | Type | Description |
|---|---|---|
| sql* | string | a single read-only SELECT/WITH over the VIRTUAL snapshot_* relations (e.g. snapshot_employees, snapshot_pay_statements, snapshot_departments). Bare physical table names are rejected. Discover the columns first with introspect_schema. |
| concepts | null | array | optional: the fact concepts this query computes, as claimable fact keys (e.g. median_income_cents) or free-form names. The server reports per concept whether a registered seed exists (cross_check can corroborate figures) or not (cross_check will return unmapped: the verified store can never corroborate them). |
| acknowledge_unverified | boolean | set true to confirm you understand results BYPASS the trust plane and are UNVERIFIED, and that you will label them so to the user. On deployments with the acknowledgment gate the FIRST raw call of a session is refused without it; one acknowledgment covers the rest of the session. |
{
"type": "object",
"required": [
"sql"
],
"properties": {
"sql": {
"type": "string",
"description": "a single read-only SELECT/WITH over the VIRTUAL snapshot_* relations (e.g. snapshot_employees, snapshot_pay_statements, snapshot_departments). Bare physical table names are rejected. Discover the columns first with introspect_schema."
},
"concepts": {
"type": [
"null",
"array"
],
"items": {
"type": "string"
},
"description": "optional: the fact concepts this query computes, as claimable fact keys (e.g. median_income_cents) or free-form names. The server reports per concept whether a registered seed exists (cross_check can corroborate figures) or not (cross_check will return unmapped: the verified store can never corroborate them)."
},
"acknowledge_unverified": {
"type": "boolean",
"description": "set true to confirm you understand results BYPASS the trust plane and are UNVERIFIED, and that you will label them so to the user. On deployments with the acknowledgment gate the FIRST raw call of a session is refused without it; one acknowledgment covers the rest of the session."
}
},
"additionalProperties": false
}Search Plumbline's own product and architecture documentation (how the verification, refusal, and trust layer itself works). Returns ranked, citable doc passages; does NOT touch employment data, and returns an empty result set honestly when nothing matches.
| Argument | Type | Description |
|---|---|---|
| limit | integer | max passages to return (default 5, capped at 10) |
| query* | string | a how-does-this-work question about Plumbline itself, e.g. the verification gate, snapshots and temporal drift, or the cross-provider corpus |
{
"type": "object",
"required": [
"query"
],
"properties": {
"limit": {
"type": "integer",
"description": "max passages to return (default 5, capped at 10)"
},
"query": {
"type": "string",
"description": "a how-does-this-work question about Plumbline itself, e.g. the verification gate, snapshots and temporal drift, or the cross-provider corpus"
}
},
"additionalProperties": false
}Search the employment fact store for a person and return a grounded, verified answer. NOTE: internal drafting is disabled on this deployment. If your client supports MCP sampling, this tool asks YOUR model to draft in the same call (verified server-side); otherwise it returns an explicit refusal, and you should use ask_prepare then ask_submit_draft to draft with your own model.
| Argument | Type | Description |
|---|---|---|
| query* | string | the employee name or search terms |
{
"type": "object",
"required": [
"query"
],
"properties": {
"query": {
"type": "string",
"description": "the employee name or search terms"
}
},
"additionalProperties": false
}Summarize benefit enrollments, optionally scoped (e.g. a department or plan). NOTE: internal drafting is disabled on this deployment. If your client supports MCP sampling, this tool asks YOUR model to draft in the same call (verified server-side); otherwise it returns an explicit refusal, and you should use ask_prepare then ask_submit_draft to draft with your own model.
| Argument | Type | Description |
|---|---|---|
| scope | string | optional scope such as a department or benefit plan |
{
"type": "object",
"properties": {
"scope": {
"type": "string",
"description": "optional scope such as a department or benefit plan"
}
},
"additionalProperties": false
}Return the session's graded trust verdict: the tier (verified / registered-query / generated-sql / corroborated / unverified / conflict / refused), which trusted steps were skipped across the session, the deterministic confidence (k of n figures store-verified, weakest figure tier, conflicts), the per-figure provenance, the per-call ledger, and the at-your-own-risk disclaimer.
No arguments.
{
"type": "object",
"additionalProperties": false
}