Skip to main content
Glama

aicomglobal

by io.github.moonspacenow-tech
OverviewAdmin

Buy a signed MEASURED trust verdict on a service (is it safe to call?)

aicom_verdict

Get a SIGNED, wallet-free, verifiable MEASURED trust verdict on a third-party service/API/agent before you call or delegate to it — the 'is this safe to trust right now?' question every registry leaves open. Signs OBSERVED BEHAVIOUR, not paperwork: three independent axes (identity, reputation, and RELIABILITY = availability + contract-stability always, plus p50/p95/p99 latency + TLS where network-probed, from aicomglobal's prober AND weighted real-caller reports), with an honest coverage of measured | partially-measured | unmeasured (a never-watched subject signs 'unmeasured', never a fake number; latency/TLS are null on availability-only subjects, never implied). Ed25519-signed + dataHash, verifiable by anyone at /.well-known/aicom-pubkey (no wallet, no chain). Reading the signals is FREE (aicom_trust / aicom_search_offerings); YOU, the agent, pay a tiny x402 fee only for the portable signed certificate. Its sibling signed action is aicom_attest (under the Oasis), which signs YOUR OWN words on the record rather than vetting a third party. QUOTE only here; mint at GET /verdict (nonce) -> POST /verdict (x402) with {offering_id} or {subject}. LIVE right now: of 3 x402 services aicomglobal is currently observing, 0 are failing or drifting — a dead endpoint eats your call fee and your task, so verify before you send one your money (recompute free at /api/x402).

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
subjectNoThe https URL of the service/API/agent to verify
pay_withNoSet to 'credits' to SETTLE now from your prepaid balance (no wallet) and get the SIGNED verdict in THIS call; omit to get the quote. Needs {subject} or {offering_id}.
offering_idNoOr a listed offering id, e.g. 'off_1a2b3c4d'
idempotency_keyNoOptional retry-safety key: the same key on a retry returns the SAME verdict, never a second debit.

Schema Changelog

Changes observed during successful MCP inspections. Dates show when Glama detected each change.

  1. Changed1 schema field changed
    • addedInput schema / properties / idempotency_key
      Added value: +{
+  "description": "Optional retry-safety key: the same key on a retry returns the SAME verdict, never a second debit.",
+  "type": "string"
+}
  2. Changed4 schema fields changed
    • addedInput schema / additionalProperties
      Added value: +false
    • addedInput schema / properties / offering_id
      Added value: +{
+  "description": "Or a listed offering id, e.g. 'off_1a2b3c4d'",
+  "type": "string"
+}
    • addedInput schema / properties / pay_with
      Added value: +{
+  "description": "Set to 'credits' to SETTLE now from your prepaid balance (no wallet) and get the SIGNED verdict in THIS call; omit to get the quote. Needs {subject} or {offering_id}.",
+  "type": "string"
+}
    • addedInput schema / properties / subject
      Added value: +{
+  "description": "The https URL of the service/API/agent to verify",
+  "type": "string"
+}
  3. First observed

TDQS

A4.3/5.0
Behavior5/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 delivers: it discloses the signing mechanism (Ed25519 + dataHash), the public verification endpoint, the fee model (x402, wallet-free), what is measured vs unmeasured, and the risk that a dead endpoint consumes the call fee. This goes well beyond a generic 'returns a verdict' statement.

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

Conciseness2/5

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

The description is over-long and dense, with repeated marketing-style emphasis (wallet-free, no wallet/no chain, MEASURED, SIGNED) and an ephemeral 'LIVE right now' status line that will age poorly. The core usage guidance is buried inside a long run-on style paragraph rather than cleanly structured.

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

Completeness4/5

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

For a no-output-schema tool, the description explains enough about what is returned (signed verdict, dataHash, public verification path) and how to invoke it (quote vs mint, GET then POST). It lacks a compact, explicit statement of the response structure, but the intended use and payment behavior are well covered.

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 structured schema already documents all four parameters. The description adds useful workflow context around subject vs offering_id and pay_with (quote vs settle), but it does not fundamentally extend the schema's parameter meaning.

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

Purpose5/5

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

The description names a specific verb and resource: buy/get a signed, wallet-free, verifiable MEASURED trust verdict on a third-party service/API/agent. It clearly distinguishes itself from siblings: aicom_trust and aicom_search_offerings are free signal readers, while aicom_attest signs your own words rather than vetting a third party.

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

Usage Guidelines5/5

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

The description explicitly says when to use this paid signed-certificate path versus the free signal-reading alternatives, and names the sibling action that does something different. It also gives the two-step flow (GET /verdict for nonce, POST /verdict with x402) and notes that omitting pay_with yields a quote, making the call-time decision clear.

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

All aicomglobal toolsInspect
Try in Browser
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources