Skip to main content
Glama

Server Details

Agent routing, safety preflight, execution receipts, best execution and verified outcomes.

If you are the author of this connector, you can claim ownership by verifying the domain or GitHub account it belongs to. Claimed connector authors can inspect health checks, view analytics, and manage their listing.
Status
Healthy
Uptime
79.3% over 63 days
Last Tested
Transport
Streamable HTTP · MCP 2025-11-25
URL

TDQS

B3.3/5.0

Scored across 1 tool

Disambiguation4/5

With only one tool there is no possibility of selecting the wrong tool, so cross-tool ambiguity is effectively absent. However, the tool is a catch-all 'control plane' that internally routes between intent resolution, safety checks, evidence paths, and Outcome execution, so its own boundaries are opaque rather than clearly delineated.

Naming Consistency3/5

There is only a single name, so no pattern can be verified across the set. The convention (snake_case with a product prefix plus the vague verb 'do') is readable but does not convey the action being performed.

Tool Count2/5

One tool is far too few for a surface described as an entire agent control plane with routing, safety boundaries, evidence paths, and paid Outcome execution. Bundling all of that into a single entry point hides capabilities that would benefit from separate, discoverable operations.

Completeness2/5

The surface offers no lifecycle operations: no way to list available capabilities or intents, inspect credit balance, check verification status, or retrieve evidence separately after execution. An agent has no discovery or follow-up path beyond firing the one opaque call.

Available Tools

1 tool
humanmirror_doAInspect

HumanMirror Agent Control Plane in one MCP tool. Use free intent routing to resolve the right capability, pre-execution safety boundary or post-execution evidence path before spending anything. For measurable deterministic work, outcome_type/input can run a verified Outcome; 6 Nexus credits are kept only on verified success.

NameRequiredDescriptionDefault
inputNoJSON input for the requested result.
intentNoOptional routing intent, for example sanitize untrusted input, protect an agent purchase, issue execution evidence, use the zero-cost sink, diagnose a payment failure, or request best execution.
dry_runNoWhen true, return a free quote and do not reserve or consume credits.
optionsNoOptional operation-specific settings.
criteriaNoOptional measurable success thresholds.
objectiveNoNatural-language measurable objective, for example: remove duplicate records and prove none remain.
contract_idNoOptional Outcome contract ID returned by a dry run.
outcome_typeNoOptional explicit Outcome type: clean_json, deduplicate_records, normalize_entity, data_quality_at_least, detect_anomalies, no_secrets, output_quality, schema_compatible, safe_preflight, execution_receipt.
route_intentNoAlias for intent when the caller wants canonical route discovery.
dispatch_onlyNoWhen true, resolve the canonical HumanMirror route without charging Nexus credits.

TDQS

A3.5/5.0
Behavior4/5

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

With no annotations, the description carries the full burden, and it does disclose the key behavioral trait: the cost model (free routing, and "6 Nexus credits are kept only on verified success"). It does not describe side effects, failure behavior, or what is returned, so it is not fully complete, but the pricing/success semantics are genuinely valuable.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two dense sentences, front-loaded with the tool's role before the routing/cost behavior. No filler, though the jargon stack ("pre-execution safety boundary," "post-execution evidence path") costs clarity without adding precision.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a 10-parameter, multi-purpose tool with no annotations and no output schema, the description explains the cost model but says nothing about what a call returns or which param combinations produce which effect. Adequate at the top level, thin for the complexity.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

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 ten parameters thoroughly; baseline is 3. The description only lightly reinforces the outcome_type/input pairing and the free vs. paid distinction, adding marginal meaning over the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose3/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description positions the tool as a broad "control plane" that does routing, safety preflight, evidence issuing, and verified Outcome execution. That is a real statement of function, but it never lands on a crisp verb+resource, so an agent can't easily tell what a single call actually accomplishes. Vague-but-directional, which fits a 3.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It gives a concrete usage pattern: use free intent routing to resolve the right capability/safety boundary/evidence path "before spending anything," and reserve payment for measurable deterministic work. It stops short of exclusions or example trigger phrases, but the when-to-use context is clear.

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

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

  1. 1 tool update
    • Changedhumanmirror_do4 fields changed
      • addedInput schema / properties / dispatch_only
        Added value: +{
        +  "description": "When true, resolve the canonical HumanMirror route without charging Nexus credits.",
        +  "type": "boolean"
        +}
      • addedInput schema / properties / intent
        Added value: +{
        +  "description": "Optional routing intent, for example sanitize untrusted input, protect an agent purchase, issue execution evidence, use the zero-cost sink, diagnose a payment failure, or request best execution.",
        +  "type": "string"
        +}
      • addedInput schema / properties / route_intent
        Added value: +{
        +  "description": "Alias for intent when the caller wants canonical route discovery.",
        +  "type": "string"
        +}
      • removedInput schema / required
        Removed value: -[
        -  "input"
        -]
  2. 1 tool update
    • First observedhumanmirror_do

Related MCP Connectors

Related MCP Servers

  • A
    license
    Not graded
    quality
    B
    maintenance
    Enables agents to route goals across multiple independent APIs, enforce constraints, reject invalid evidence, and return verified outcomes with tamper-evident receipts.
    MIT
  • A
    license
    Not graded
    quality
    A
    maintenance
    Enables agents to route every action through a pre-execution gate that returns allow, escalate-to-human, or deny verdicts, backed by deterministic hard-rule blocks plus probabilistic gray-zone scoring, and to run a resumable orchestration loop covering routing, quality gates, stop-loss, acceptance, and escalation. Every decision, arbitration between conflicting agents, and human approval is written to an append-only hash-chained, Ed25519-signed ledger that can be postmortemed, calibrated, alert-scanned, and exported as offline verification bundles or OTel spans.
    1
    MIT
  • A
    license
    Not graded
    quality
    B
    maintenance
    Enables AI agents to resolve typed routing, loop-stall arbitration, and tool safety checks locally at sub-millisecond latency, avoiding unnecessary frontier LLM calls. It enforces reversible execution checkpoints, token budgets, and decayed episodic memory for safe, privacy-first autonomous operation.
    7
    MIT
Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources