Plumbline — a trust layer for LLM answers

BYO: Prepare Grounded Prompt

ask_prepare

Read-only

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.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "question": "<question>"
    },
    "name": "ask_prepare"
  }
}

Input Schema

Name	Required	Description
`history`	No	optional prior conversation turns (role user\|assistant) to thread into the composed prompt for follow-up questions
`question`	Yes	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`	No	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

Output Schema

Name	Required	Description	Default
`ask_id`	No
`refusal`	No
`messages`	No
`question`	No
`session_id`	No
`prepare_key`	No
`instructions`	No
`max_output_tokens`	No
`original_question`	No
`expires_in_seconds`	No

Schema Changelog

Changes observed during successful MCP inspections.

First observedAug 23, 2026

TDQS

A4.8/5.0

Behavior5/5

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

Beyond the readOnlyHint annotation, the description discloses meaningful behavioral details: prepare holds no server state, the receipt is minted only at ask_submit_draft, generation happens on the connected model's side so no LLM credential reaches the server, and unanswerable drafts can never earn a verified verdict. No annotation contradiction exists.

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 front-loads the tool's role and step in the flow, and each sentence generally earns its place given the complexity of the handoff protocol. It is long and densely worded, so most of the same information could be delivered in fewer words, but it is still well-structured with an opening summary and focused callouts.

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 two-stage BYO workflow with an output schema, the description is nearly complete: it explains the prepare/receives handoff, identify semantics, verbatim question requirement, original_question fallback, answerability after an unanswerable question, no redaction rule, no LLM credential exposure, and the recommended path to ask_submit_draft. Nothing essential is left unclear.

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: it insists the question be passed verbatim and explains why — do not expand, narrow, or reword it. It also clarifies the conditional requirement for original_question and how to fold in essential conversation context. It only slightly under-serves the history parameter, which is otherwise well covered by the schema.

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 names a specific verb-resource pair — 'run the server-side trust plane for a business question' — and specifies the deliverables: a composed prompt plus a single-use prepare_key/ask_id. It also self-identifies as 'BYO step 1 of 2,' clearly distinguishing it from ask_submit_draft and the other sibling tools.

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?

The description explicitly sequences the usage: run prepare first, then write the draft from the returned prompt, then 'submit it with ask_submit_draft.' It also gives edge-case guidance: only a policy refusal stops at prepare, while unanswerable questions still prepare but are force-refused at submit. This is strong when-to-use and when-not-to-use guidance.

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

All Plumbline — a trust layer for LLM answers tools Inspect

Try in Browser

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

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?