Deterministic decision layer for autonomous agents. Reproducible PROCEED, REVIEW, SKIP verdicts.
Liveness probe. Returns engine_version and transport.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the behavioral disclosure burden. It communicates that this is a lightweight health check and names the expected return fields, implying a safe read-only probe. It does not discuss auth or rate limits, but the probe semantics make significant hidden behavior unlikely.
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 two short phrases, front-loading the operation type and immediately stating the return values. Every word 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?
The tool takes no inputs, so no parameter guidance is needed. It names the return fields ('engine_version and transport'), and since there is no output schema, this gives the agent sufficient information about what to expect. Nothing essential 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?
The input schema has zero parameters and the schema description coverage is 100%, so the description does not need to explain parameters. This matches the baseline of 4 for no-parameter tools.
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 the tool as a 'Liveness probe' and specifies what it returns ('engine_version and transport'), making its purpose clear and differentiating it from report/simulate/validate/version siblings. It lacks an explicit verb+resource construction but the health-probe framing is unambiguous.
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 phrase 'Liveness probe' provides clear context for when to use this tool: checking that the service is alive. It does not explicitly mention alternatives or exclusions, but the purpose is distinct enough that an agent can infer appropriate usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Post-decision outcome feedback. Accepts request_id + outcome (RUG/LOSS/OK/WIN/UNKNOWN) plus optional post-trade metadata. Aggregated deterministically for SKIP-rate vs realized-outcome correlation.
| Name | Required | Description | Default |
|---|---|---|---|
| notes | No | Optional free-text notes about the outcome (post-mortem, context, references). Stored verbatim for audit. | |
| venue | No | Venue or platform where the trade/signal was executed (e.g. 'raydium', 'jupiter', 'uniswap-v3'). Free-form label for downstream grouping. | |
| outcome | Yes | Real-world outcome once known. RUG = rug-pull / total loss; LOSS = negative PnL; OK = neutral / no material result; WIN = positive PnL; UNKNOWN = outcome not yet observable. | |
| request_id | Yes | The `request_id` returned by a prior quesen.validate call. Ties the reported outcome back to the exact decision that produced it. | |
| signal_hash | No | Optional hash/fingerprint of the original signal (URL, token address, message id) so outcomes can be joined across systems that don't share Quesen request_ids. | |
| realized_pnl | No | Realized profit/loss in the caller's chosen unit (e.g. USD, SOL, ETH). Sign convention: positive = profit, negative = loss. Fed into the aggregate `pnl_mean` counter. | |
| elapsed_seconds | No | Seconds elapsed between the original quesen.validate decision and the observation of this outcome. Non-negative. | |
| client_request_id | No | Optional caller-side trace id. Echoed verbatim in the response for cross-system correlation. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states 'Aggregated deterministically for SKIP-rate vs realized-outcome correlation', which hints at deterministic processing, but it doesn't disclose whether the call is idempotent, reversible, or what happens on duplicate submissions. For a write-operation tool (posting outcome feedback), missing information about side effects, idempotency, and error handling is a significant gap. The description is too thin on behavioral traits.
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 two sentences, tightly written, with the essential purpose front-loaded. The first sentence states what it does and what it accepts; the second mentions the deterministic aggregation purpose. Every sentence contributes value with no filler. It could arguably be split into a structured list for the outcome enum, but it remains concise and readable.
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 tool with 8 parameters and no output schema, the description adequately covers the core purpose but omits workflow context beyond what the schema provides (e.g., the dependency on a prior quesen.validate call is only in the schema, not the description). It also doesn't mention error scenarios or return behavior. Given the schema covers parameter semantics thoroughly, the description is acceptable but not comprehensive. A bit more workflow guidance would improve it.
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 already documents all 8 parameters, including the outcome enum values and the requirement that request_id come from a prior quesen.validate call. The description adds a little context by mentioning the aggregation correlation (linking outcome and realized_pnl), but it doesn't provide meaningful semantics beyond what the schema already states. Baseline 3 is appropriate given high coverage.
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 opens with 'Post-decision outcome feedback', which clearly states the verb and resource (reporting outcomes after a decision). It explicitly lists the required inputs (request_id + outcome) and the accepted outcome enum, which distinguishes it from siblings like quesen.validate (which produces decisions) and quesen.simulate (which predicts outcomes). The purpose is unambiguous and specific.
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 phrase 'Post-decision outcome feedback' clearly implies the tool is used after a decision has been made and the outcome is known, which is a clear context. It doesn't explicitly name alternatives or exclusions, but the sibling tool names (validate, simulate) make the use case obvious without needing explicit 'when not to use' statements. The absence of explicit alternatives is a minor gap, but the context is clear enough for an agent to select it correctly.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Counterfactual scoring. Compare the baseline decision against a simulated decision under caller-supplied weights_override / thresholds_override. Free sales asset — not charged against key.
| Name | Required | Description | Default |
|---|---|---|---|
| domain_age_days | No | Age of the target domain in days. Same feature as quesen.validate; combined with the (possibly overridden) weights to produce a counterfactual risk score. | |
| engagement_ratio | No | Engagement ratio in [0, 1]. Same feature as quesen.validate; used with the (possibly overridden) weights during simulation. | |
| weights_override | No | Optional per-feature weight override used ONLY for this simulation. When null (or omitted) the engine uses its production weights. Does NOT mutate global state. | |
| client_request_id | No | Optional caller-side trace id. Echoed verbatim in the response for cross-system correlation. | |
| scam_keyword_count | No | Count of known scam keywords detected. Same feature as quesen.validate; used with the (possibly overridden) weights. | |
| thresholds_override | No | Optional decision-threshold override used ONLY for this simulation. When null the engine uses its production thresholds. Does NOT mutate global state. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the disclosure burden. It does reveal that calls are free/not key-charged and that this is a simulation rather than a production decision, but it omits output shape, side-effect behavior, and where the baseline decision comes from.
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?
Three short declarative statements with no filler. The core action is front-loaded, and the billing note is useful additional context placed at the end.
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 schema richly documents parameters, but there is no output schema and the description never says what the response contains. It also leaves the 'baseline decision' undefined. For a simulation tool an agent may need more context to verify the result is the expected counterfactual comparison.
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 already documents all six parameters. The description adds that weights_override and thresholds_override are the mechanism for the counterfactual simulation, but this largely echoes the parameter descriptions. No significant new parameter-level meaning is added.
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 leads with 'Counterfactual scoring' and a specific action: compare the baseline decision against a simulated decision under caller-supplied weight/threshold overrides. This clearly identifies what the tool does and separates it from the validate/report/health/version 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 'Free sales asset — not charged against key' line gives billing context, and 'counterfactual scoring' implies when it should be used. However, it never explicitly names alternatives (e.g., quesen.validate for real decisions) or states when not to use this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Deterministic pre-decision risk validation for autonomous agents. Returns PROCEED / REVIEW / SKIP plus risk_score, confidence, and named conflict triggers. Same input -> same output; every response embeds engine_version + weights + thresholds for full replay.
| Name | Required | Description | Default |
|---|---|---|---|
| domain_age_days | No | Age of the target domain in days. | |
| engagement_ratio | No | Engagement ratio in [0, 1]. | |
| client_request_id | No | Optional caller-side trace id (echoed in response). | |
| scam_keyword_count | No | Count of known scam keywords detected. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral burden. It discloses determinism ('Same input -> same output'), replayability via embedded engine_version/weights/thresholds, and the nature of outputs. It does not explicitly state side effects, but 'validation' strongly implies a read-only operation.
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 tight sentences front-load the core purpose and then provide deterministic/replay guarantees. Every sentence adds distinct information, with no filler or repetition.
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 description sufficiently explains what the tool returns given there is no output schema: the decision, risk score, confidence, conflict triggers, and replay metadata. It does not cover error behavior or exact response structure, but for a validation tool with all-optional parameters this is a 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%, so the schema fully documents all four parameters. The description adds no parameter-level meaning, which is acceptable but not value-adding; baseline 3 applies.
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 states a clear purpose: deterministic pre-decision risk validation. It also specifies the exact output categories (PROCEED / REVIEW / SKIP) and supporting signals, which differentiates it from siblings like health, report, simulate, and version.
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 phrase 'pre-decision risk validation for autonomous agents' gives a clear usage context: call before making a decision. It does not explicitly name alternatives or when not to use the tool, but the context is strong enough to guide selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Full engine configuration — weights, thresholds, versions.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden; it does disclose the configuration domains (weights, thresholds, versions) and, by having no inputs, suggests a read-only inspection. It does not explicitly state that invocation has no side effects or describe the returned structure, which leaves some ambiguity.
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?
One compact sentence with no filler; the key scoping phrase 'Full engine configuration' is front-loaded and the examples that follow clarify 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?
For a parameterless, no-output-schema tool with no annotations, the description is mostly sufficient: an agent knows what resource is exposed and what categories of data it contains. It would be stronger if it explicitly said whether it returns/sets configuration, but the context makes that unlikely.
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?
There are zero parameters, and the schema enforces an empty object, so the description does not need to explain parameter behavior. Baseline 4 applies.
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 identifies the resource as the full engine configuration and enumerates contents (weights, thresholds, versions), which clearly separates it from health/report/simulate/validate siblings. It stops short of an explicit verb, but the empty input schema implies this is a retrieval operation.
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 the tool is used when the current engine configuration is needed, and the sibling names provide obvious contrast. However, it does not state when not to use it, mention prerequisites, or name an alternative.
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. Dates show when Glama detected each change.
quesen.report8 fields changedInput schema / properties / client_request_id / descriptionAdded value: +"Optional caller-side trace id. Echoed verbatim in the response for cross-system correlation."Input schema / properties / elapsed_seconds / descriptionAdded value: +"Seconds elapsed between the original quesen.validate decision and the observation of this outcome. Non-negative."Input schema / properties / notes / descriptionAdded value: +"Optional free-text notes about the outcome (post-mortem, context, references). Stored verbatim for audit."Input schema / properties / outcome / descriptionAdded value: +"Real-world outcome once known. RUG = rug-pull / total loss; LOSS = negative PnL; OK = neutral / no material result; WIN = positive PnL; UNKNOWN = outcome not yet observable."Input schema / properties / realized_pnl / descriptionAdded value: +"Realized profit/loss in the caller's chosen unit (e.g. USD, SOL, ETH). Sign convention: positive = profit, negative = loss. Fed into the aggregate `pnl_mean` counter."Input schema / properties / request_id / descriptionAdded value: +"The `request_id` returned by a prior quesen.validate call. Ties the reported outcome back to the exact decision that produced it."Input schema / properties / signal_hash / descriptionAdded value: +"Optional hash/fingerprint of the original signal (URL, token address, message id) so outcomes can be joined across systems that don't share Quesen request_ids."Input schema / properties / venue / descriptionAdded value: +"Venue or platform where the trade/signal was executed (e.g. 'raydium', 'jupiter', 'uniswap-v3'). Free-form label for downstream grouping."quesen.simulate11 fields changedInput schema / properties / client_request_id / descriptionAdded value: +"Optional caller-side trace id. Echoed verbatim in the response for cross-system correlation."Input schema / properties / domain_age_days / descriptionAdded value: +"Age of the target domain in days. Same feature as quesen.validate; combined with the (possibly overridden) weights to produce a counterfactual risk score."Input schema / properties / engagement_ratio / descriptionAdded value: +"Engagement ratio in [0, 1]. Same feature as quesen.validate; used with the (possibly overridden) weights during simulation."Input schema / properties / scam_keyword_count / descriptionAdded value: +"Count of known scam keywords detected. Same feature as quesen.validate; used with the (possibly overridden) weights."Input schema / properties / thresholds_override / descriptionAdded value: +"Optional decision-threshold override used ONLY for this simulation. When null the engine uses its production thresholds. Does NOT mutate global state."Input schema / properties / thresholds_override / properties / review / descriptionAdded value: +"Risk score at or above which the counterfactual decision becomes REVIEW (below `skip`)."Input schema / properties / thresholds_override / properties / skip / descriptionAdded value: +"Risk score at or above which the counterfactual decision becomes SKIP."Input schema / properties / weights_override / descriptionAdded value: +"Optional per-feature weight override used ONLY for this simulation. When null (or omitted) the engine uses its production weights. Does NOT mutate global state."Input schema / properties / weights_override / properties / domain_age / descriptionAdded value: +"Weight applied to the domain_age_days feature during counterfactual scoring."Input schema / properties / weights_override / properties / engagement / descriptionAdded value: +"Weight applied to the engagement_ratio feature during counterfactual scoring."Input schema / properties / weights_override / properties / scam_keywords / descriptionAdded value: +"Weight applied to the scam_keyword_count feature during counterfactual scoring."quesen.healthquesen.reportquesen.simulatequesen.validatequesen.versionClaiming proves that you control a remote MCP connector. It does not move, proxy, or interrupt the server.
Open the connector listing, choose Claim ownership, and sign in to Glama.
Complete one verification method:
GitHub identity — fastest for official registry listings. For a namespace such as io.github.alice/server, link the matching GitHub user, then choose Claim with GitHub. An organization namespace such as io.github.acme/server also needs that organization to have installed the Glama AI GitHub App and approved its permissions, because GitHub discloses organization membership only to apps it has installed. Use HTTP or DNS when it has not.
HTTP challenge — works when you can deploy a public file. Generate a token, publish the exact JSON Glama shows at /.well-known/glama.json on the same origin as the connector, then choose Check HTTP challenge.
DNS challenge — works when you control DNS but cannot change the server. Generate a token, create the exact TXT record Glama shows, wait for it to propagate, then choose Check DNS challenge.
After verification, Glama sends a confirmation email and gives you access to listing details, thumbnails, health checks, and analytics. Keep the HTTP file or DNS record in place: Glama periodically checks it and ownership remains verified while the token is discoverable.
The HTTP ownership file has this structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"claim": "glama_claim_..."
}Claim tokens are opaque, stable, and bound to the signed-in Glama account. They contain no email address or other personal information. If Glama can no longer discover a verified HTTP or DNS token, it starts a seven-day grace period before removing claim-based access. Restore the same token during that period to keep ownership verified. Never publish an email address, Glama session token, GitHub token, or connector credential as ownership proof.
If verification fails, confirm that you copied the current token exactly. The HTTP file must be public, return valid JSON with a successful HTTP response, and stay on the connector's origin. DNS changes may need more time to propagate. A claim cannot transfer to a different origin or hostname: if the connector target changes, Glama starts the grace period and the new target must be claimed separately after the previous claim is released.
For a connector linked to the official MCP Registry, registry updates continue to replace its name, description, and URL by default. After claiming, open Manage connector and enable Use Glama listing details as the source of truth if edits made on Glama should be preserved. Categories and thumbnails are always managed on Glama; registry linkage and technical connection settings continue to sync.
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
To improve your MCP server's ranking:
Claim ownership of the server listing
Complete the server profile with an accurate description and thumbnail
Provide a test profile so Glama can connect to and evaluate the server
Keep tool definitions clear and complete to earn a high Tool Definition Quality Score (TDQS)
Route real usage through the Glama Gateway; more recorded successful server uses also improve the ranking
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.
No comments yet. Be the first to start the discussion!
Pre-execution governance for AI agents. Deterministic PASS/FAIL/REVIEW verdicts, replayable proof.
Deterministic AI code review, with an audit record. Governance inside the agent loop.
Deterministic reasoning stack for AI agents: simulate, decide & compute, plus cross-domain tools.
Deterministic operations reconciliation for AI agents: COMPLETE, INCOMPLETE, or NEEDS_REVIEW.
Add one secure layer between your agents and this server.
Each tool has a clearly distinct role: health for liveness, validate for pre-decision risk, report for post-decision feedback, simulate for counterfactual scoring, and version for configuration. Even the minor overlap between health and version is resolved by their descriptions (liveness probe vs. full config).
All tools share a consistent 'quesen.' prefix and lowercase single-word naming, which is predictable. However, the suffix words are not uniformly verbs or nouns (health, version vs. validate, simulate), so the semantic pattern is mildly inconsistent.
Five tools is well-scoped for a decision-layer server. Each tool covers a distinct core concern without redundancy or excessive surface area.
The set covers the core decision lifecycle: validate pre-decision, report post-decision, simulate counterfactuals, and inspect configuration. The main minor gap is that aggregated report results are described but there is no tool to retrieve them.
