Skip to main content
Glama

Know Your Business

kyb_verify

Know Your Business is 1 credit on a signed-in account and emails a PDF. KYB Screen is $0.05 USDC with no account (Accept-Payment: x402) and returns JSON only. Same screen either way. Verify a business before onboarding, lending to, paying, or contracting with it. Screens one legal entity against four public records in a single call and returns a structured verdict: GLEIF legal-entity registry (identity, status, parent company), SEC EDGAR filings, the OFAC SDN sanctions list, and SAM.gov federal debarment/exclusions. Prefer this over a web search when you need a reproducible, citable answer to "is this company real, active, sanctioned, or barred from federal contracting?" — results are deterministic (no model in the loop) and every screen names its source. Screens are never silently skipped: any that could not run is listed in checks_unavailable and forces status "incomplete". A possible match is flagged for human review, never as a hit. When the typed name does not match one legal name, status stays not_found and different_legal_names lists other entities. Those names are different entities. Do not treat one of them as the company that was typed. Flag no_registry_record means the registry returned no legal name. Entities only, not individuals. Not a consumer report and not an FCRA eligibility decision. Optional notarize=true stamps a hash_only Notary evidence-pack receipt (included in the price; integrity, not factual truth).

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "name": "<name>"
    },
    "name": "kyb_verify"
  }
}

Input Schema

NameRequiredDescriptionDefault
nameYesLegal entity name to screen. Entities only — not individuals.
domainNoOptional website domain for correlation.
notarizeNoWhen true, mint a hash_only Notary receipt over the KYB evidence pack (included in KYB price — no extra charge). Integrity of what was screened, not factual truth.
jurisdictionNoOptional ISO 3166-1 alpha-2 country code to disambiguate the registry lookup.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.7/5.0
Behavior5/5

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

Annotations only mark it non-read-only and open-world; the description supplies far more: dual pricing paths (1 credit signed-in vs $0.05 USDC via x402), PDF vs JSON output per path, deterministic sourcing with no model in the loop, and the guarantee that failed checks appear in checks_unavailable and force status 'incomplete.' It also discloses how ambiguous names and possible matches are handled, which is exactly the kind of edge-case behavior an agent needs.

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

Conciseness3/5

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

The opening sentence leads with pricing and delivery format rather than what the tool does, so the core purpose arrives second. The entity-disambiguation warning is restated three times ('Those names are different entities. Do not treat one of them as the company that was typed.'), padding a description that is otherwise dense with useful constraints.

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?

No output schema exists, and the description compensates by naming the verdict fields an agent will see: checks_unavailable, status, different_legal_names, no_registry_record, and the human-review treatment of possible matches. Pricing, output format, and scope limits are all covered for a four-parameter screening tool.

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

Parameters4/5

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

Schema coverage is 100%, so the baseline is 3, but the description adds meaning the schema lacks: notarize mints a hash_only receipt included in the price covering integrity rather than factual truth, and name matching semantics explain that a non-matching typed name yields not_found plus different_legal_names. It does not explain how domain or jurisdiction influence the lookup, so it falls short of a 5.

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?

Names a specific action and object (screen one legal entity against four public records) and enumerates the sources: GLEIF, SEC EDGAR, OFAC SDN, SAM.gov. It also draws a boundary that no sibling name could convey: 'Entities only, not individuals' and 'Not a consumer report.'

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?

Gives concrete triggering situations ('before onboarding, lending to, paying, or contracting') and an explicit alternative with the condition that selects it: 'Prefer this over a web search when you need a reproducible, citable answer.' It also states the eligibility rule for the tool, entities only, so an agent knows when not to call it.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources