aura

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

Annotations indicate a non-read-only, non-idempotent operation, but the description adds important behavior: no decryption happens unless reveal=true, and plaintext inputs are automatically sealed first. It does not cover side effects or cost, but those are not central to invoking the tool correctly.

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?

Two concise sentences deliver the core behavior, the reveal exception, and the routing to an alternative. There is no filler, and the most important information is front-loaded.

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?

For a 4-parameter tool with no output schema, the description covers the critical decision points: what inputs mean, how plaintext is handled, when decryption occurs, and when to use a different tool. The return shape is only implied ('does not decrypt' implies sealed output unless reveal=true), but that is inferable.

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?

The schema already covers 75% of parameters with descriptions, and the description adds meaning beyond the schema: plaintext values in inputs are sealed automatically before computation, and reveal controls decryption behavior. This resolves ambiguity that the schema alone leaves open.

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?

The description states a specific behavior: compute on sealed handles, optionally sealing plaintext inputs first, and never decrypting unless reveal=true. It also distinguishes itself from the sibling fhe_private_eval by noting that fhe_private_eval should be preferred for one-shot AI work.

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?

It explicitly provides an alternative and a condition: 'Prefer fhe_private_eval for one-shot AI work.' This tells an agent when not to use this tool and which sibling to use instead. It implies fhe_compute is for more general or repeated private computation.

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

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

Annotations already set readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds meaningful context that this operation reveals the plaintext value and that the handle comes specifically from fhe_encrypt/fhe_compute/fhe_private_eval, which helps the agent anticipate the tool's behavior beyond the structured fields.

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?

Two sentences, no filler, and the core action is front-loaded. The usage condition is stated in the second sentence without unnecessary elaboration.

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?

For a one-parameter reveal tool, the description fully explains what it does, where the handle comes from, and when to invoke it. There is no output schema, but the purpose of revealing plaintext implies the return value sufficiently. Nothing needed to call it correctly is missing.

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% with the handle parameter described as 'Handle such as ct_1'. The description enriches this by specifying the handle originates from fhe_encrypt, fhe_compute, or fhe_private_eval, giving the agent a stronger mental model of what value to pass.

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?

The description clearly states the tool decrypts a handle produced by fhe_encrypt, fhe_compute, or fhe_private_eval, and that doing so reveals the plaintext result. The verb 'decrypt' plus the resource 'handle' and the source tools make the purpose unmistakable and distinct from siblings.

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?

It explicitly says to call this only when the user asked to see the plaintext result, providing a clear condition that separates this tool from the other FHE operations. No alternative is named, but the when-to-use guidance is explicit and sufficient for a tool with this simple role.

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

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

Annotations already indicate this is not read-only and not idempotent. The description adds beyond that by disclosing the handle behavior and warning the model not to treat the handle as plaintext, which is valuable operational context.

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?

Two sentences with no fluff. The first sentence states the operation, the second explains the return value and a critical operational warning. Every sentence earns its place.

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?

For a four-parameter tool with a fully described schema, the description covers the essential operational context: what is encrypted, what is returned, and how the handle should be treated. Some extra detail about encryption behavior or key modes could help, but the schema already covers the parameters.

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 description coverage is 100%, so the schema fully documents all four parameters including the 'public' and 'raw' flags. The description adds no parameter-level details, which is acceptable given the schema carries that burden.

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?

Description opens with a specific verb and resource: 'Encrypt a value for private AI compute.' It also states the return shape (a short ct_ handle) and distinguishes the tool's role from siblings like fhe_decrypt and fhe_status by focusing on encryption and later use.

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?

Clear context is provided: encrypt when you need private AI compute, and the returned handle is meant for later tools. It does not explicitly list when-not-to-use or name alternative tools, so it stops short of a 5.

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

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

Annotations already declare readOnlyHint and idempotentHint, so safety is covered. The description adds the useful behavioral context that the tool returns op names which are inputs for fhe_private_eval, showing the relationship between tools. No contradiction with annotations exists.

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?

The description is a single, front-loaded sentence that immediately states the action and object, then provides examples and a usage pointer. Every element earns its place with no repetition or filler.

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?

For a simple, parameterless, read-only listing tool, the description is complete: it states what is listed, gives examples, and explains how the result is used downstream. Annotations cover the safety profile, and no output schema exists but the return value (a list of op names) is implied clearly.

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?

The tool has zero parameters, so the baseline is 4. The description adds nothing about parameters because none exist, and the schema is fully covered. This is appropriate for a parameterless listing tool.

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?

The description states a specific verb ('List') and resource ('private ops this MCP server can run'), with concrete examples (add, mean, concat). It clearly identifies this as an enumeration tool rather than an execution or status tool, distinguishing it from the sibling tools fhe_status, fhe_encrypt, fhe_decrypt, and fhe_compute.

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?

The description explicitly tells the agent what to do with the output: 'Pass these names to fhe_private_eval.' This gives clear context for when to use the tool. It does not explicitly state when not to use it or name alternatives, but the purpose is simple enough that the guidance is sufficient.

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

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

The description discloses the key behavioral trait beyond annotations: it runs without showing intermediates and 'optionally reveales only the final answer.' This materially informs the agent about privacy semantics. It does not cover edge cases like failure or repeated-call behavior, but annotations already handle idempotency and mutation hints, so the extra description is valuable and non-contradictory.

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?

The description is three short sentences with no filler. The most important choice ('main agent tool') and routing ('Prefer this over encrypt/compute/decrypt') come early, and each clause adds information.

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?

For a 4-param tool with full schema coverage and no output schema, the description explains the core privacy contract and final-output behavior. It doesn't specify what happens when reveal is false, but the overall selection guidance is complete enough for an agent; a bit more return-format detail would make it fully complete.

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?

The schema already covers all four parameters at 100% described. The description restates the op list and adds that values are sealed before compute, which is a mild lifecycle detail, but it does not add meaningfully beyond the schema descriptions for domain or reveal. Baseline 3 is appropriate.

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?

The description identifies a specific verb ('seals inputs, runs the op') and a clear resource (one-shot private FHE compute). It also distinguishes itself as 'the main agent tool' and explicitly prefers it over encrypt/compute/decrypt, making its identity clear against siblings.

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?

The description explicitly says 'Prefer this over encrypt/compute/decrypt', which gives clear routing guidance toward this tool among alternatives. It lacks a stated condition for when the alternative pipeline would be necessary (e.g., when intermediate ciphertexts are needed), so it falls just short of full when/when-not guidance.

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

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

Annotations already declare readOnly, openWorld, and idempotent, so the agent knows this is safe and repeatable. The description adds that the tool reports whether private-compute tools are online, which is useful but does not disclose additional side effects, return behavior, or failure modes. No contradiction with annotations.

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?

Two short sentences contain exactly the needed information: what the tool is an when to call it. The instruction is front-loaded with the purpose first an the placement next, with no wasted text.

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?

Given zero parameters, rich annotations, and a simple health-check purpose, the description is almost complete. It clarifies that the tool tells whether private-compute tools are online, but it does not describe the response format or what to do if the status is offline, which would beg more useful without an output schema.

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?

The tool has zero parameters, so the schema imposes no burden and the description does not need to explain any. Baseline 4 is appropriate for a no-parameter tool.

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?

The description states a specific purpose — an MCP health check — and explicitly instructs the agent to call it first to confirm private-compute tools are online. This distinguishes it from the sibling compute/encrypt/decrypt tools, which are operations rather than status checks.

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?

The description gives an explicit 'call this first' directive, making the intended usage timing clear. It does not explicitly say when not to use it, but for a no-parameter health check the instruction to invoke it before private-compute tools is sufficient guidance.

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