Dr. Animesh Sinha Roy PRO

Thanks, those labels are clearer than mine and I’ve adopted them.

Tool-input validation is always on: the server checks the arguments it receives.

Request-to-action consistency is now optional on the server side. There is a new check_answer tool: a client sends the user’s question and its draft, and the server compares the request with the arguments recorded in that session. Your two traces are now tests, and I ran them against the live Space:
(1) requested p = 0.8, submitted p = 0.8 → verdict ok;
(2) requested p = 0.8, submitted p = 0.9 → verdict problems: “the user’s request contains the value(s) 0.8 but no tool call in this turn used it”, although every number in the draft is a correct result.

As you say, the server can only judge what it receives: a client that does not call check_answer, or paraphrases the question, is not checked. The README section “Which checks apply where” describes this boundary.

Thanks for reading closely, and good question. The answer check does not cover an external agent. It runs inside the built-in chat (graph.py), on my model’s draft, against the user’s question and the tool results. Over MCP the server sees only the tool arguments, never the user’s question or the client’s final text, so the explanation is the client’s responsibility.

What carries across the boundary is the tool layer: typed schemas with fixed choices, range and completeness checks (e.g. Kraus operators must satisfy ΣK†K = I), handle and session errors, and results that state what was computed. Requested-parameter binding does not: if a client silently changes p = 0.8 to 0.9, the server computes 0.9 correctly and cannot know it was not asked for. The change is visible only in the client’s tool-call record.

A side-by-side example is a good idea; I’ll look at adding one.

Thanks, this was a real gap. You're right: grounding (every number appears in a tool result) and physical bounds (C in [0, 1], CHSH ≤ 2√2) both pass when the tool is called with p = 0.03 and the result is quoted faithfully. The answer is consistent with itself, but it describes the wrong experiment.

What I added:

• Parameter binding. Each value in the question is bound to the channel named just before it, in the same sentence. "Global depolarizing with p = 0.3 and local depolarizing with p = 0.1" becomes (global_depolarizing, 0.3) and (depolarizing, 0.1). These pairs are compared with the actual arguments of the noise-tool calls. A mismatch is sent back to the model with the exact difference.

• No silent pass. If the model ignores the note, the answer reaches the user with a visible warning that names the requested and the used value.

• Swapped values. Asking for global 0.3 + local 0.1 but running global 0.1 + local 0.3 is also caught. A check on values alone misses it, because every number is used somewhere.

Your comment also made me look for the same failure one level up: a correct number attached to the wrong quantity. A real run on the Space wrote "p_W = 0.7, so concurrence = 0.7". 0.7 is grounded (it's 1 − p), but the concurrence is 0.55. That is now sent back as well.

Scripted-model tests replay your exact case (asked 0.3, called 0.03), the ignored note and the swap:
https://github.com/animeshQKD/quantum-information-agent/blob/main/test_parameter_binding.py

A known limit: the binding is lexical. Phrasings like "p = 0.3 and 0.1 respectively" aren't bound yet; in that case the check stays silent rather than guessing.

If you have other adversarial cases in mind, I'd be glad to add them as tests.