Skip to main content
Glama

aicomglobal

by io.github.moonspacenow-tech
OverviewDiscussionsAdmin

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 7 x402 services aicomglobal is currently observing, 4 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.

  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

A3.9/5.0
Behavior5/5

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

No annotations are provided, so the description carries the full behavioral burden and does so unusually well: Ed25519 + dataHash signing, verification at /.well-known/aicom-pubkey, no wallet/chain, free reading vs paid certificate, x402 fee, and an explicit honesty contract (measured | partially-measured | unmeasured, latency/TLS null on availability-only subjects, never a fake number). This is exactly the extra context annotations would otherwise have to supply.

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 purpose is front-loaded, but the body is a dense promotional wall of capitalized phrases, em-dashes, and a volatile marketing claim ('LIVE right now: of 7 x402 services... 4 are failing or drifting') that will go stale and does not help the agent select or invoke the tool. Several sentences restate the same free-vs-paid point, so not every sentence earns its place.

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?

With no output schema, the description must explain return values and largely does: the three axes, coverage labels, signing/dataHash, and null semantics for latency/TLS. The free-then-pay flow and nonce/mint endpoint sequence are covered. The residual gap is the unresolved quote-vs-settle ambiguity, which matters for a paid action.

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 subject, pay_with, offering_id, and idempotency_key — baseline 3 applies. The prose adds conceptual framing around the quote/settle flow but no syntax or format detail beyond the schema, so it neither compensates for nor falls below the schema's coverage.

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

Purpose4/5

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

The description names a specific verb+resource (buy/get a signed MEASURED trust verdict on a third-party service) and explicitly distinguishes itself from aicom_trust/aicom_search_offerings (free signal reading) and aicom_attest (signs your own words). The one blemish is internal muddle about whether the tool settles or only quotes: the prose says 'QUOTE only here; mint at GET /verdict -> POST /verdict', while the schema's pay_with says it can settle and return the signed verdict in this call.

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?

There is clear when-to-use context ('before you call or delegate to it', 'a dead endpoint eats your call fee') and named alternatives with selection conditions: read free via aicom_trust/aicom_search_offerings, use aicom_attest for your own attestation. The only gap is that the quote-vs-pay routing is stated two different ways, leaving the agent unsure whether this call itself transacts.

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
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources