QMA N-representability on a 2×2 rational 2-RDM. rho2 and n are decimal strings. Float SDP refused. Same law as math_court domain qma_nrep.
| Name | Required | Description | Default |
|---|---|---|---|
| n | No | particle count as decimal string. e.g. 2 | |
| rho2 | No | a11,a12|a21,a22 as num/den rationals. e.g. 1/2,0/1|0/1,1/2 |
Changes observed during successful MCP inspections.
Input schema / properties / n / descriptionPrevious value: -"particle count as decimal string"New value: +"particle count as decimal string. e.g. 2"Input schema / properties / rho2 / descriptionPrevious value: -"a11,a12|a21,a22 as num/den rationals"New value: +"a11,a12|a21,a22 as num/den rationals. e.g. 1/2,0/1|0/1,1/2"Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It does disclose a real behavioral trait - that float-based SDP input is refused, forcing rational/decimal-string input - plus the 2x2 size limit. However, it says nothing about what a verification returns, failure modes, or whether an N-representability violation is reported as a boolean or witness.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Very terse, four front-loaded fragments with no filler. The telegraphic style trades clarity for brevity, but every fragment carries information and the purpose comes first.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no annotations and no output schema, the description should explain the return value and failure semantics, but it does not. An agent cannot tell what a successful or failed verification yields, nor how 'refused' input is surfaced, leaving a real gap for a validation tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the schema already documents both parameters; baseline 3 applies. The description adds mild context (both are 'decimal strings', rho2 is a num/den rational matrix), but this slightly tensions with the schema, which describes rho2 as num/den rationals while the description calls it a decimal string.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb+resource: verifying QMA N-representability of a 2x2 rational 2-RDM. This is distinct from the amplitude/QFT/Shor verification siblings, though the reference to 'math_court domain qma_nrep' is more of a cross-reference than a clean differentiation. Jargon-heavy but unambiguous about what it computes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Only weak usage guidance: 'Float SDP refused' implies rational input is mandatory and 'Same law as math_court domain qma_nrep' hints at a relationship with a sibling. There is no explicit when-to-use or when-not-to-use this versus math_court or the other verify_* tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add one secure layer between your agents and this server.