This server exposes MCP tools for encrypted/private computation: status checks, op discovery, sealing values, running FHE operations, and revealing final results.
Check private-compute status and list available private ops (add, sub, mul, div, mean, concat, compare, etc.).
Seal plaintext values (int, float, string, binary) into ciphertext handles (ct_...), optionally returning raw ciphertext or using public-key encryption.
Run private operations on sealed handles and/or plaintext inputs, with optional final-result decryption.
Decrypt sealed handles to reveal plaintext only when explicitly requested.
Use one-shot fhe_private_eval to seal inputs, compute an operation, and optionally reveal only the final answer.
Work with encrypted integers, floats, strings, and binary data; no model inference, SQL, or retrieval.
Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@aura Privately add 25 and 17."
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
FHE is the foundation. Aura AI is the application. MCP connects your assistant to encrypted tools.
FHE lets software calculate with data in its encrypted form. Aura's flagship AI application gives that foundation a practical purpose: useful AI with a defined privacy and key-custody model. MCP is the connection from your assistant to the capabilities exposed here.
Aura reports GPT-OSS-20B encrypted inference at 20+ tokens/second on one RTX PRO 6000 Blackwell GPU, with prompt read-in below 2.3 seconds. This is the website's internal benchmark, not a speed measured by this MCP or an independent validation. Benchmark source and scope.
Three ways to experience Aura | Where to go |
1. Aura AI Chat — invitation-only: a business question and a follow-up | |
2. Evaluate applications: encrypted databases, messaging or private inference | |
3. Learn and build through MCP from Cursor, Claude Desktop or VS Code |
Understand the differences, keys and evidence. Start with the AI application for the product experience; use MCP to explore the supported numeric integration. AI Chat is invitation-only. Request an invitation or arranged demonstration via gen@afhe.io. The public MCP learning demo is open and does not require a Chat invitation.
MCP helps users learn how FHE works, integrate supported encrypted calculations into applications, and explore their potential. Start with a guided public lesson, then map your own use case to its computation, keys and result workflow. The public demo needs installation and host configuration. Confidential application integration also needs local encryption, key custody and authenticated service setup; browser WASM integration is planned. From learning to building.
The AI application is accessed separately; this package does not run model inference. Its executable tools provide encrypted numeric computation. Aura's confirmed FHE database and FHE-AI LLM inference applications are completed and available on request via gen@afhe.io. 中文说明.
These buttons open instructions. Install Node.js 20+, then run these two commands in Terminal (macOS/Linux) or PowerShell (Windows):
npm install -g @aurafhe/mcp@preview
aura-fhe-mcp --config cursor --demoUse claude or vscode instead of cursor for those apps. Paste the generated
settings into your app's MCP configuration and reconnect.
Exact steps and paste locations. No Git, npm account, local
computation engine or demo key setup is needed. Settings must be generated on the
machine that runs the MCP; paths from a cloud workspace do not work on your laptop.
Then ask:
What can I do with Aura? Show me the AI application first, then explain what I can run here.
Your assistant explains the published AI benchmark and the three experiences:
the separate AI application, application evaluations, and the MCP integration.
Within MCP, choose the optional public-sample lesson or the developer tools.
Connecting alone does not start a chat or
calculation. In clients with MCP prompts, choose What can I do with Aura?
(aura_demo). The overview works without a backend connection; a separate status
check or learning lesson checks the service.
This is release 0.5.0-rc.8, an explicitly labelled preview. To pin it, install
@aurafhe/mcp@0.5.0-rc.8. To update an existing installation, run the installation
command again, regenerate settings and fully restart your client.
Related MCP server: uMCP
Add, subtract, multiply and divide encrypted integers and floats.
Compose sums, products, float averages and weighted sums on the coprocessor.
Discover available operations, measure request latency and save encrypted results.
Explore application access and distinguish published benchmarks from live observations.
Numeric arithmetic is a core FHE use case. Binary-operation support is a planned capability milestone; it is not required for numeric computation to be homomorphic. An application uses these building blocks with its own input, key and output workflow. SQL, retrieval and model inference are not current MCP tools. Tool reference.
Teach me encrypted computation using Aura's public sample lesson.
The assistant calls aura_start with experience: "learn", explains FHE, prepares
encrypted public samples, requests a calculation and saves the encrypted result.
It handles identifiers for you. Ask questions or say “one step at a time.”
The aura_learn MCP prompt starts this same lesson.
The first example combines public totals 25 and 17. Expected sum: 42. The MCP returns encrypted data; the separate synthetic verifier checks actual numerical results outside the conversation. Follow-up samples 7.5, 2.5 and 2 support an encrypted average. Observed checks and reproduction.
Public-sample demo: Aura manages its demo keys and can decrypt its demo data. Use public examples here. Confidential deployments need a verified key-custody and authorization design. Anything entered in your host assistant is visible to that assistant provider. Security model.
Describe your application to the assistant using public or invented information. It can help map your task to available operations and explain the client/server configuration you need. Integration steps and the path to simpler setup.
The package contains the connection adapter, not the proprietary computation engine. It accepts no custom plaintext, secret keys or arbitrary file paths in tool arguments. Operator-provisioned encrypted bundles require an authenticated compute-only deployment and separate recipient processing; this path is not Verified mode. The unpublished reference branch is a separate engineering fixture.
Application walkthrough · Investor demo · Architecture · Verification · Security
Compute on sealed handles (and optional plaintext, which is sealed first). Does not decrypt unless reveal=true. Prefer fhe_private_eval for one-shot AI work.
| Name | Required | Description | Default |
|---|---|---|---|
| op | Yes | AI op name from fhe_ops, e.g. add, mul, mean, concat | |
| domain | Yes | ||
| inputs | Yes | Handles (ct_…) and/or plaintext values | |
| reveal | No | Decrypt the final result |
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.
Decrypt a handle from fhe_encrypt / fhe_compute / fhe_private_eval. Only call this when the user asked to see the plaintext result.
| Name | Required | Description | Default |
|---|---|---|---|
| handle | Yes | Handle such as ct_1 |
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.
Encrypt a value for private AI compute. Returns a short handle (ct_…) the model can pass to later tools. The model must not treat the handle as plaintext.
| Name | Required | Description | Default |
|---|---|---|---|
| raw | No | Also return the raw ciphertext blob | |
| value | Yes | Plaintext to seal | |
| domain | Yes | Value type: int, float, string, or binary | |
| public | No | Use public-key encrypt when the data owner should not share a secret key |
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.
List the private ops this MCP server can run (add, mean, concat, …). Pass these names to fhe_private_eval.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
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.
The main agent tool. Seals inputs, runs the op (add, mul, mean, concat, …) without showing intermediates, and optionally reveals only the final answer. Prefer this over encrypt/compute/decrypt.
| Name | Required | Description | Default |
|---|---|---|---|
| op | Yes | add | sub | mul | div | mean | concat | compare | … (see fhe_ops) | |
| domain | Yes | int for integers, float for real math, string for text, binary for bits | |
| reveal | No | If true (typical for AI answers), return plaintext of the final result only | |
| values | Yes | Plaintext inputs. They are sealed before compute. |
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.
MCP health check. Call this first so the agent knows the private-compute tools are online.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
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.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v0.4.0fhe_computefhe_decryptfhe_encryptfhe_opsfhe_private_evalfhe_statusScored across 6 tools
fhe_status and fhe_ops are clearly distinct, and fhe_encrypt/fhe_decrypt have narrow roles, but fhe_compute and fhe_private_eval overlap substantially. The descriptions partially resolve this by positioning fhe_private_eval as the preferred high-level tool, but an agent could still misselect between low-level compute and one-shot evaluation.
All tools share a consistent fhe_ prefix and snake_case style, which makes the family readable and predictable. The main deviation is that status and ops are nouns rather than verb commands, while private_eval is an adjective-verb rather than a clean verb_noun form.
Six tools is a well-scoped set for a private-compute MCP server. Each tool maps to a necessary step in the health-check, operation-listing, encryption, compute, and decryption workflow, and none feel extraneous.
The server covers the core private-compute lifecycle: health, capability discovery, encryption, computation, high-level evaluation, and decryption. Minor gaps like explicit key management or handle inspection are not required for the described use case, so the surface is functionally complete.
Confidential AI execution with a post-quantum receipt on every job — verifiable by anyone.
MCP-native Trust Infrastructure for AI Agents. Persistent encrypted memory with Trust Quotient.
A secret store for AI agents: the agent never sees the plaintext.
Sovereign E2E cloud storage for AI agents. Zero-knowledge, RGPD-compliant.
