QnEvt Verifiable Randomness MCP
Server Details
Verifiable random decisions, audit sampling, fair selection, and proof verification using QnEvt.
- Status
- Healthy
- Last Tested
- Transport
- Streamable HTTP
- URL
Glama MCP Gateway
Connect through Glama MCP Gateway for full control over tool access and complete visibility into every call.
Full call logging
Every tool call is logged with complete inputs and outputs, so you can debug issues and audit what your agents are doing.
Tool access control
Enable or disable individual tools per connector, so you decide what your agents can and cannot do.
Managed credentials
Glama handles OAuth flows, token storage, and automatic rotation, so credentials never expire on your clients.
Usage analytics
See which tools your agents call, how often, and when, so you can understand usage patterns and catch anomalies.
Tool Definition Quality
Average 3.5/5 across 7 of 7 tools scored. Lowest: 2.8/5.
Each tool has a distinct purpose: sampling, fair selection, tie-breaking, proof retrieval, listing agent/public proofs, and verification. Even though fair_select and tie_break both involve picking from options, their contexts differ clearly.
All tools follow the consistent pattern `qnevt_<verb>_<noun>` with underscores, using descriptive verbs like audit, fair_select, get, list, tie_break, verify.
Seven tools cover the essential operations of generating, listing, retrieving, and verifying randomness proofs without being excessive or insufficient.
The toolset covers core lifecycle: random generation (sampling, selection, tie-breaking), proof management (list, get), and verification, with no obvious gaps for a verifiable randomness server.
Available Tools
7 toolsqnevt_audit_sampleBInspect
Sample a random subset of items or records securely using the requested entropy_source, defaulting to server_csprng via auto. Generates proof_url and proof_json_url.
| Name | Required | Description | Default |
|---|---|---|---|
| items | Yes | Dataset to sample from | |
| context | No | Reason for sampling | |
| visibility | No | Proof visibility. Use private to hide raw dataset fields. | |
| sample_size | Yes | Number of items to sample | |
| entropy_source | No | Entropy source (default auto) |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It mentions 'securely' and generating proof URLs but lacks details on side effects, permissions, rate limits, or whether the operation is destructive. For a sampling tool, more behavioral context is needed.
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 extremely concise with two sentences, no redundant phrasing. Every word adds value, and it is front-loaded with the core purpose.
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 no output schema, the description partially covers the return (proof URLs) but omits details about randomness guarantees, idempotency, or any constraints. For a tool with 5 parameters and no output schema, more completeness is needed.
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 baseline is 3. The description adds minimal extra meaning beyond the schema: it mentions the default entropy_source and that proof URLs are generated, but does not elaborate on parameters like items, sample_size, context, or visibility beyond what is in the schema.
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 samples a random subset securely, mentions the entropy source default, and indicates it generates proof URLs. This distinguishes it from sibling tools like qnevt_fair_select (different selection) and proof retrieval tools.
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?
No explicit guidance on when to use this tool versus alternatives. The description implies it's for auditable sampling with proofs, but does not state when to choose qnevt_audit_sample over qnevt_fair_select or other siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
qnevt_fair_selectAInspect
Pick 1 or more items fairly from a list using the requested entropy_source, defaulting to server_csprng via auto. Generates proof_url and proof_json_url that should be shared with the user.
| Name | Required | Description | Default |
|---|---|---|---|
| count | No | Number of items to pick (default 1) | |
| context | No | Reason or context for this selection | |
| options | Yes | List of options to choose from | |
| visibility | No | Proof visibility. Use private for sensitive inputs. | |
| entropy_source | No | Entropy source (default auto) | |
| allow_duplicates | No | Whether to allow picking the same item multiple times (default false) |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It discloses that proof_url and proof_json_url are generated and should be shared, but does not mention any side effects, authentication needs, or rate limits.
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 wasted words. The first sentence captures the core action, the second explains the output. Efficiently structured.
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 6 parameters and no output schema, the description covers the main purpose and output but lacks details on the behavior of optional parameters like allow_duplicates or visibility, and does not explain the verification flow.
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 baseline is 3. The description adds context about the default entropy source and proof generation, but does not significantly elaborate on individual parameter meanings beyond the schema.
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 verb ('Pick') and resource ('1 or more items fairly from a list'), and distinguishes this from sibling tools like qnevt_audit_sample or qnevt_verify_proof by focusing on fair selection with proof generation.
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 implies use when a fair random selection is needed, but does not explicitly state when not to use this tool versus alternatives like qnevt_tie_break or qnevt_audit_sample.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
qnevt_get_proofBInspect
Fetch the JSON record of a specific QnEvt proof by its ID.
| Name | Required | Description | Default |
|---|---|---|---|
| proof_id | Yes | The public ID of the proof |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the burden. It only states 'Fetch the JSON record' without disclosing whether the operation is read-only, any side effects, error conditions, or permissions required. This is insufficient for a tool with no 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?
The description is a single, clear sentence with no filler words. It efficiently conveys the core action and scope.
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?
The tool has one required parameter, no output schema, and no annotations. The description does not explain what a 'proof' is, what fields the JSON record contains, or any error handling. Given the missing output schema, the description should provide more context on the return value.
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% (proof_id has a description in schema). The description adds no additional meaning beyond the schema, so 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 clearly states the verb 'Fetch', the resource 'JSON record of a specific QnEvt proof', and the method 'by its ID'. It distinguishes from sibling list and verification tools by specifying a single-record fetch by ID.
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 implies usage when you have a specific proof ID, but it does not explicitly state when to use this tool versus siblings like qnevt_list_public_proofs or qnevt_verify_proof. No exclusions or alternatives are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
qnevt_list_agent_proofsAInspect
List recent verifiable random decision proofs with pagination and optional decision_type filter.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Maximum proofs to return (1-100, default 20) | |
| offset | No | Pagination offset (default 0) | |
| decision_type | No | Optional decision type filter |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries full burden. It discloses the tool lists 'recent' proofs with pagination and optional filtering, but fails to clarify ordering direction (e.g., descending by time), empty response behavior, or authentication requirements. Adequate but not complete.
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?
A single 12-word sentence that front-loads the verb and resource, conveying all essential information without extraneous text. Every word 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 3-param listing tool with no output schema, the description covers the core functionality. However, it omits details about the response format (e.g., list of proof objects, total count) which would aid the agent. Minor gap.
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% (all 3 parameters are documented in the schema). The description adds no additional parameter meaning beyond summarizing 'pagination' and 'optional decision_type filter', so 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 clearly states the action (List), the resource (verifiable random decision proofs), and key features (pagination, optional decision_type filter), effectively distinguishing it from siblings like qnevt_get_proof (single proof) and qnevt_list_public_proofs (public scope).
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 implies usage context (filtering by decision_type, pagination) but does not explicitly state when to use this tool versus alternatives like qnevt_get_proof or qnevt_list_public_proofs. No usage exclusions or recommendations are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
qnevt_list_public_proofsAInspect
List recent public verifiable random decisions.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears full responsibility. It indicates a read-only listing operation but does not mention ordering, pagination, or the meaning of 'recent'. Behavioral traits beyond listing are not disclosed.
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 sentence of 5 words, front-loaded with the verb and resource. No wasted words, and it is appropriately sized for the simplicity of the tool.
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 the tool has no parameters and no output schema, the description could explain what is returned (e.g., list of proof IDs or objects) and any ordering. It only says 'list ... decisions', which is somewhat vague. There is room for more completeness.
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 input schema has no parameters (0 parameters, 100% schema coverage). The description does not need to add parameter information since none exist. Baseline of 4 is appropriate as there is no additional value to add.
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 'List recent public verifiable random decisions' uses a specific verb ('List') and clearly identifies the resource ('recent public verifiable random decisions'). It distinguishes from sibling tools like qnevt_get_proof (specific proof) and qnevt_list_agent_proofs (filtered by agent) by implying a broader scope.
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 a clear purpose but does not explicitly state when to use this tool versus alternatives like qnevt_get_proof or qnevt_verify_proof. The context is implied but not explicit, so usage guidance is minimal.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
qnevt_tie_breakAInspect
Break a tie between options fairly using the requested entropy_source, defaulting to server_csprng via auto. Generates proof_url and proof_json_url.
| Name | Required | Description | Default |
|---|---|---|---|
| context | No | Reason for the tie-break | |
| options | Yes | List of tied options to choose between | |
| visibility | No | Proof visibility. Use private for sensitive inputs. | |
| entropy_source | No | Entropy source (default auto) |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description should disclose behavioral traits. It mentions generating proof URLs and default entropy source, but lacks details on side effects, authentication needs, or what happens with invalid inputs.
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 redundancy, front-loaded with key action and output details. Every sentence adds value.
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 tool with 4 params and no output schema, the description covers purpose and output but misses details on return format, validation, and usage context. Adequate but not comprehensive.
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 baseline is 3. The description adds minimal extra meaning beyond schema, only noting the default entropy source which is already in schema.
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 action (break a tie), the resource (options), and the fairness aspect. It distinguishes from sibling tools like qnevt_fair_select by specifically mentioning tie-breaking and proof generation.
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 implies usage for tie-breaking but does not explicitly contrast with sibling tools like qnevt_fair_select or provide when-not-to-use guidance. It mentions entropy source defaulting, which is helpful.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
qnevt_verify_proofCInspect
Cryptographically verify a proof dynamically by cryptographic commitment-based, deterministic replay verifiable resimulation.
| Name | Required | Description | Default |
|---|---|---|---|
| count | No | Original count parameter (if applicable) | |
| items | No | Original items (required if proof input was private) | |
| context | No | Original context (if applicable) | |
| options | No | Original options (required if proof input was private) | |
| records | No | Alias for items | |
| proof_id | Yes | The public ID of the proof to verify | |
| selected | No | The original selected outcome to verify against | |
| sample_size | No | Original sample_size parameter (if applicable) | |
| allow_duplicates | No | Original allow_duplicates parameter (if applicable) |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavior but only states the action. It does not mention side effects, permissions, or what happens on success/failure.
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 sentence and relatively concise, but its jargon-heavy structure detracts from readability.
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?
Despite 9 parameters and no output schema, the description offers minimal context about the verification process, result format, or parameter relationships.
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 baseline is 3. The description adds no parameter-specific information beyond what the schema already provides.
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 identifies the tool's purpose: verify a proof cryptographically. However, the phrasing is overly technical with jargon like 'deterministic replay verifiable resimulation,' which may obscure clarity.
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?
No guidance is provided on when to use this tool versus sibling tools like qnevt_get_proof or qnevt_audit_sample, nor any conditions or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Claim this connector by publishing a /.well-known/glama.json file on your server's domain with the following structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"maintainers": [{ "email": "your-email@example.com" }]
}The email address must match the email associated with your Glama account. Once published, Glama will automatically detect and verify the file within a few minutes.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
Discussions
No comments yet. Be the first to start the discussion!