Skip to main content
Glama

biii

by io.github.philpof102-svg

till_vet_merchant

MainStreet safe-to-pay preflight on a merchant address. Returns the hosted oracle read (advisory) AND a LOCAL CLASSIFIER verdict computed on this node via trust-core (pure, zero-oracle) — so a verdict holds even if the oracle is down. Vet the RECIPIENT before paying.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
addressYes0x merchant address
resourceUrlNooptional — the endpoint/resource URL you would pay; enables the local phishing/plain-http/admin-path URL lens

Schema Changelog

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

  1. First observed

TDQS

A4.5/5.0
Behavior4/5

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

With no annotations provided, the description adequately discloses that the tool returns both an oracle read and a local verdict, and that the local verdict is available even if the oracle is down. It lacks mention of any destructive actions, which is appropriate for a preflight check.

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

Conciseness5/5

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

The description is three sentences with no fluff. It efficiently conveys purpose, key features, and a usage directive, earning 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?

Considering no output schema, the description sufficiently explains return types (oracle read and local verdict). It covers both parameters and their roles. Minor gap: exact return format is unspecified, but the description is still clear enough.

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

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The description adds meaning beyond the schema by specifying '0x merchant address' for the address parameter and explaining that resourceUrl enables local phishing/URL lens analysis. This enriches the parameter semantics given 100% schema coverage.

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 clearly states the tool is a safe-to-pay preflight check on a merchant address, distinguishing it from sibling vetting tools for other entities (agent, asset, etc.). It specifies the outputs: oracle read and local classifier verdict.

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?

The description advises to 'Vet the RECIPIENT before paying,' implying use before payment transactions. However, it does not explicitly state when not to use this tool or provide guidance on choosing among sibling vetting tools.

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

All biii 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.

TDQS

B3.1/5.0
Disambiguation3/5

Many tools have distinct, well-named purposes (vet_agent vs vet_merchant), but there is notable overlap between till_trust and till_vet_merchant (both provide trust verdicts), and till_launch_funder vs till_funder_history are closely related. The descriptions are detailed enough to differentiate, but an agent could still misselect between a few pairs.

Naming Consistency3/5

All tools share the till_ prefix, but the pattern is mixed: some use verb_noun (check_invoice, create_charge, watch_wallet) while others are noun phrases (key_exposure, open_approvals, rug_powers) or bare nouns (floor, trust, roll). This is readable but not predictable, so an agent cannot reliably guess a tool name from a verb.

Tool Count2/5

At 29 tools, this server exceeds the 25+ threshold that signals an overgrown toolkit. Even with a broad domain, many tools are one-off niche scanners (till_b20_authentic, till_floor, till_meter) that inflate the surface and could be consolidated or externalized.

Completeness4/5

The toolkit covers the payment lifecycle comprehensively: create charges/invoices, check payments, verify delivery, generate receipts, rolls, and accounting exports. It also spans identity, trust, security scanning, and theft tracing. Minor gaps exist (no update/cancel for charges, no token-general vetting), but the non-custodial, read-only design makes these acceptable.

Resources