HubVibe: Pay-per-Call Agent Tools: Web Search, Email Verify, KYC Screening, Stocks, Crypto, News

Contact and sanctions screening (not identity verification)

hubvibe_contact_screen

Read-onlyIdempotent

Screen a name against sanctions lists, evaluate email deliverability and disposable signals, validate a phone number's numbering plan and inspect IP geography/network. Returns findings, per-check completion, and a screening risk indicator. Never proves document authenticity, ownership or liveness, and is NOT complete KYC or identity verification. Inconclusive/failed checks cannot produce a low-risk result. Input: any of name, email, phone, ip; optional country/birth_year. $0.10 per call. Returns: input{}, risk (low | review | high), verification_status (not_verified), assessment_status (complete | incomplete), check_statuses{}, flags[{code, severity, detail}], checks{sanctions, email, phone, ip}, checks_run[], checks_failed[], notes[], checked_at.

Input Schema

Name	Required	Description
`ip`	No	The client's IPv4 or IPv6 address.
`name`	No	Person or company name to screen against sanctions lists.
`email`	No	Email address to verify.
`phone`	No	Phone number, international (+44 20 7946 0958) or national with `phone_region`.
`country`	No	Country the person says they are in (US or United States), compared with phone and IP.
`language`	No	Optional BCP-47 language tag (en, ja, ko, pt-BR): the human-readable strings of the result (notes, details, reasons) are translated into this language; data, codes, numbers and URLs are untouched. Default: as produced.
`birth_year`	No	Birth year, to narrow sanctions matches for a person.
`phone_region`	No	Two-letter country for a national-format phone number.

Output Schema

Name	Required	Description	Default
`result`	Yes
`status`	Yes
`worker`	Yes
`price_usd`	Yes
`provenance`	Yes
`receipt_id`	Yes
`attribution`	No
`receipt_url`	Yes
`billing_warning`	No

Schema Changelog

Changes observed during successful MCP inspections.

Changed2 schema fields changedNov 1, 2026

removedInput schema / anyOf

Removed value: -[
-  {
-    "required": [
-      "name"
-    ]
-  },
-  {
-    "required": [
-      "email"
-    ]
-  },
-  {
-    "required": [
-      "phone"
-    ]
-  },
-  {
-    "required": [
-      "ip"
-    ]
-  }
-]

addedInput schema / minProperties
```
Added value: +1
```

AddedOct 26, 2026

TDQS

A4.4/5.0

Behavior5/5

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

Beyond the annotations, the description discloses pricing ($0.10 per call), the risk and completion semantics, the verification_status limitation, and the rule that inconclusive or failed checks cannot produce a low-risk result. This is strong behavioral context for a read-only screening tool.

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?

The description is dense but well-structured, front-loading what the tool does and following with limitations, accepted inputs, cost, and return fields. The long return-value enumeration is somewhat redundant because an output schema exists, but the overall text remains focused for a complex multi-check tool.

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

Completeness5/5

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

For a multi-signal screening tool, the description covers the key scope, exclusions, input flexibility, cost, status semantics, and risk behavior. Annotations and output schema carry the remaining structural detail, so an agent has enough context to invoke it correctly.

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 parameter meaning is already fully documented in the schema. The description summarizes that any of name, email, phone, or IP can be supplied and that country/birth_year are optional, but it adds little syntax or meaning beyond the schema and omits mention of language and phone_region.

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 the exact screening actions: sanctions name screening, email deliverability and disposable checks, phone numbering validation, and IP geography/network inspection. It also explicitly distinguishes itself from identity verification and KYC, which is the key sibling distinction an agent needs.

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 clearly states the tool accepts any of name, email, phone, or IP, with optional country/birth_year, and gives explicit exclusions such as not proving document authenticity, ownership, liveness, or complete KYC. It does not explicitly route the agent to sibling alternatives like hubvibe_sanctions_screen or hubvibe_identity_check, so it falls short of full when/when-not guidance.

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

All HubVibe: Pay-per-Call Agent Tools: Web Search, Email Verify, KYC Screening, Stocks, Crypto, News tools Inspect

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.