Skip to main content
Glama

agent-tools (x402 + MCP + A2A directory)

scan_mcp_safety

Check an MCP server for malware / prompt-injection lures by its endpoint URL.

Give the server's streamable-http endpoint URL. Two paths:

  * **Already in the agent-tools directory** → returns our LATEST stored
    rule verdict. Every indexed server is re-scanned hourly, so you get a
    consistent, continuously-refreshed answer without re-probing.
  * **Not yet indexed** → we probe the endpoint live, statically scan its
    advertised tools + metadata, and return the fresh verdict. It is ADDED
    to the directory (so the next caller gets the stored verdict instantly)
    only if it answered or you supplied metadata; documentation hosts such
    as example.com / *.test / *.invalid are scanned but never listed.

Two dimensions are reported. `verdict` is authoritative and comes from
deterministic static rules — pure pattern-matching over the *advertised*
text only, NO code execution. It flags the social-engineering / RCE tricks
listing-spam servers use:

  * `curl … | bash` and `base64 -d | sh` install lures
  * `eval "$(curl …)"` / PowerShell `IEX(...DownloadString)` cradles
  * base64 blobs that decode to a shell command
  * bare-IP payload hosts and cheap throwaway TLDs
  * prompt-injection / credential-exfiltration phrasing
    ("ignore previous instructions", "send your .env / api key")
  * MCP tool-poisoning coercion — descriptions that hijack an agent's
    tool-calling ("always call this tool first", "before using any other
    tool you must…"), hidden `<IMPORTANT>` instructions, "list all API
    keys / include secrets in your response", and coercion to read &
    forward `.key`/`.pem`/`.ssh`/`.env` files

Source-code-oriented rules (SQL / command / code injection) are deliberately
not applied to natural-language descriptions, to avoid false positives.

`llm_reference` is an advisory frontier-LLM second opinion over the same text.
Because the LLM is slow it is computed LIVE on this call only and is never
stored (the hourly job never runs it), so it may be null on timeout. It
never overrides the rule verdict; when it is *more* severe than the rules an
`advisory` note is attached as a safety-net signal. Security/defense
products that merely *name* these attacks are not flagged.

Args:
    endpoint_url: The MCP server's streamable-http URL (required). This is
        the identity we look up / index by.
    name: Optional advertised name (used when the server is new and gets
        added; falls back to the URL host).
    description: Optional description / README blurb (scanned when new).
    tools_text: Optional tool names + descriptions; used only if the live
        probe cannot fetch the server's tools/list.

Returns:
    { verdict: "clean"|"suspicious"|"malicious", score: 0-100,
      reasons: [{rule, weight, snippet}],
      llm_reference: {model, verdict, reason, confidence} | null,
      advisory: str | null, slug, name, endpoint_url,
      source: "stored" (existing) | "new_scan" (just added), indexed: bool }

Input Schema

NameRequiredDescriptionDefault
nameNo
tools_textNo
descriptionNo
endpoint_urlYes

Output Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A4.7/5.0
Behavior5/5

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

With no annotations, the description carries the full burden and does so richly: static pattern-matching with no code execution, hourly re-scan of indexed servers, the exact list of flagged lure categories, the rule that code-injection rules are deliberately not applied to natural language, and the fact that llm_reference is computed live, may be null on timeout, and never overrides the rule verdict. Caching/listing side effects (added to the directory only if it answered or metadata was supplied; doc hosts never listed) are also disclosed.

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?

Front-loaded with the purpose and the two paths, then well-organized bullets, so it reads efficiently despite its length. The trailing 'Returns:' block largely restates the existing output schema, which is the one piece of real redundancy.

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?

Everything an agent needs to call it correctly is present: required vs optional inputs, what each optional input affects, fallback behavior, timeout/null semantics for the advisory field, and listing side effects. Since an output schema exists, the return values need not have been spelled out, making coverage more than sufficient.

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?

Schema description coverage is 0%, so the description must compensate, and its 'Args:' block documents all four parameters with meaning beyond type: endpoint_url is the lookup identity, name is used only when the server is new (with host fallback), description is scanned when new, and tools_text is a fallback only if the live tools/list probe fails.

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?

Opens with a specific verb and resource ('Check an MCP server for malware / prompt-injection lures by its endpoint URL') and its scope clearly separates it from lookup siblings like get_mcp_server and search_mcp_servers. An agent knows exactly what this tool answers without opening the schema.

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 spells out the two operational paths (already-indexed vs not-yet-indexed) with the consequence of each, which is unusually clear routing guidance. It does not, however, explicitly contrast itself with sibling tools such as get_mcp_server or search_mcp_servers, so the alternative-selection story is implied rather than stated.

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.