Skip to main content
Glama

Check a target before you install, connect, pay or trade

onchain_agent_preflight
Read-onlyIdempotent

USE WHEN you are about to install a package, clone a repo, connect to an MCP endpoint, pay an agent, or trade a token, and you want to know what is on record about it FIRST. Pass exactly one of repo, package, endpoint, agent or token.

Returns a verdict — go | caution | no | unknown — with one evidence line per check, each naming the field it was read from and when that field was written. The rules are written down in lib/preflight.ts and cited by id in rule.

RULE ENFORCED: a verdict names WHAT WAS CHECKED AND WHEN. It is never a security review, a quality judgment or a statement about returns, and unknown means Sato Hub holds no record — not that something is wrong. An unlisted endpoint gets ONE live handshake (initialize + tools/list, 8 s cap) and can never come back go: a handshake is not a record. For agent=: we confirm the ERC-8004 registration exists, fetch its registration file, and report the services it DECLARES; only a declared MCP service is probed.

TOKEN LANE (token + chain, EVM only): keyless chain reads — bytecode presence and size, the ERC-20 views, the Clanker v4 factory's OWN deployment record (tokenDeploymentInfo, not a bytecode heuristic), and the Uniswap v3 factory across the four standard fee tiers against wrapped native. Every field is nullable and a null carries the reason it is null. PERMANENTLY NULL, and said so in the evidence: holder concentration (no keyless public source — explorers are not scraped) and Uniswap v4 / non-Uniswap liquidity (a v4 poolId cannot be reconstructed without the PoolKey). The deployer address needs an optional explorer key. A pool existing is not depth; a locker holds a position on the terms its own code enforces. Nothing in this lane says safe, audited, rug or scam — those are not readings.

SKILL LANE (skill): a skill is a DOCUMENT an agent follows, which is exactly why it is worth checking first — the ClawSwarm skills needed no malware, only text telling the agent to generate a wallet and post the private key. Evidence is the static disclosure the weekly sweep already produced: hosts the text names, whether it generates or handles keys, whether it asks for a credential, whether it pipes a remote script into a shell, what tools it grants itself — each finding WITH the lines that produced it — plus installs, when it was last seen in its registry, and whether a host it names belongs to a listed project. Nothing is fetched from a registry and no skill is executed. A DISCLOSURE DESCRIBES: it never says safe, it never says malicious, an empty flag list is "nothing matched" rather than a pass, and the registry's own scan result is attributed to that registry by name.

Returns (json): { verdict, rule, target: { kind, value, slug, name, sato_url, verify_url }, evidence: [{ check, result, source_field, checked_at }], checked_at, caveat, rules, token?, skill? }. token and skill are the raw reports for those lanes. Read-only.

Example: { repo: "coinbase/agentkit" } · { endpoint: "https://mcp.example.com/v1" } · { agent: "base:42" } · { token: "0x1bc0c42215582d5A085795f4baDbaC3ff36d1Bcb", chain: "Base" } · { skill: "clawhub/solana-wallet" }

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
repoNoA GitHub repository: a URL or bare owner/name, e.g. 'coinbase/agentkit'.
agentNoAn ERC-8004 agent reference, <chain>:<id>, e.g. 'base:42'. Chains: Ethereum, Base, Arbitrum, Optimism, Polygon, BNB Chain, Avalanche, Gnosis, Robinhood Chain.
chainNoChain for `token`: Base, Ethereum, Arbitrum, Robinhood Chain. Anything else (Solana included) answers 'unknown' with the reason, never a guess.
skillNoAn agent skill: '<registry>/<id>' (registries: clawhub, skillssh, skills.sh, skills-sh, github), or the skill id alone when it is unique. Reads the static disclosure already on record — nothing is fetched from a registry and no skill is ever executed.
tokenNoAn ERC-20 token contract address, e.g. '0x1bc0c42215582d5A085795f4baDbaC3ff36d1Bcb'. Needs `chain`. EVM only in v1.
packageNoAn npm or PyPI package name, e.g. 'solana-agent-kit'. A trailing @version is ignored.
endpointNoAn https MCP endpoint URL. If it is not in the directory it gets a live initialize + tools/list handshake, capped at 8 seconds.
response_formatNoOutput format: 'markdown' (default) or 'json'.markdown

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • addedInput schema / properties / skill
      Added value: +{
      +  "description": "An agent skill: '<registry>/<id>' (registries: clawhub, skillssh, skills.sh, skills-sh, github), or the skill id alone when it is unique. Reads the static disclosure already on record — nothing is fetched from a registry and no skill is ever executed.",
      +  "maxLength": 300,
      +  "type": "string"
      +}
  2. Changed2 schema fields changed
    • changedInput schema / properties / agent / description
      Previous value: -"An ERC-8004 agent reference, <chain>:<id>, e.g. 'base:42'. Chains: Ethereum, Base, Arbitrum, Optimism, Polygon, BNB Chain, Avalanche, Gnosis."New value: +"An ERC-8004 agent reference, <chain>:<id>, e.g. 'base:42'. Chains: Ethereum, Base, Arbitrum, Optimism, Polygon, BNB Chain, Avalanche, Gnosis, Robinhood Chain."
    • changedInput schema / properties / chain / description
      Previous value: -"Chain for `token`: Base, Ethereum, Arbitrum. Anything else (Solana included) answers 'unknown' with the reason, never a guess."New value: +"Chain for `token`: Base, Ethereum, Arbitrum, Robinhood Chain. Anything else (Solana included) answers 'unknown' with the reason, never a guess."
  3. Changed2 schema fields changed
    • addedInput schema / properties / chain
      Added value: +{
      +  "description": "Chain for `token`: Base, Ethereum, Arbitrum. Anything else (Solana included) answers 'unknown' with the reason, never a guess.",
      +  "maxLength": 40,
      +  "type": "string"
      +}
    • addedInput schema / properties / token
      Added value: +{
      +  "description": "An ERC-20 token contract address, e.g. '0x1bc0c42215582d5A085795f4baDbaC3ff36d1Bcb'. Needs `chain`. EVM only in v1.",
      +  "maxLength": 120,
      +  "type": "string"
      +}
  4. Added

TDQS

A4.6/5.0
Behavior5/5

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

Annotations already cover safety (readOnly, idempotent, non-destructive), yet the description adds substantial behavior: the 8 s single live handshake for unlisted endpoints, that unknown means 'no record held' rather than 'bad', permanently-null fields with reasons, no scraping/no execution, and evidence attribution per field. This is far beyond what the structured annotations provide.

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 USE WHEN trigger and the lane breakdown are front-loaded, and each paragraph maps to a target kind. It is on the long side and includes some asides (e.g. the locker/pool-depth remark) that inform calibration more than invocation, costing a point on tightness.

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?

With no output schema, the description carries the return contract: it enumerates verdict, rule, target, evidence fields with source_field and checked_at, caveat, and the lane-specific token?/skill? reports. Combined with the rule-enforcement and null-handling notes, an agent has everything needed to call and interpret it.

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 description coverage is 100%, so the baseline is 3, but the description adds cross-parameter semantics the schema does not: 'Pass exactly one of repo, package, endpoint, agent or token', the token-requires-chain dependency, and the EVM-only restriction for the chain param. That raises it above baseline.

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 first sentence names a specific verb (check/preflight) and enumerates the exact target kinds (repo, package, endpoint, agent, token, skill), and the lane descriptions spell out what is actually verified in each. This is clearly distinguishable from siblings like search_skills or get_agent_passport.

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?

'USE WHEN you are about to install a package, clone a repo, connect to an MCP endpoint, pay an agent, or trade a token' gives explicit triggering conditions, and 'Pass exactly one of...' constrains invocation. It also states what the verdict is NOT (not a security review, not a quality judgment), which functions as when-not guidance. No sibling alternative is named, which keeps it below a 5.

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.