Skip to main content
Glama

vuln-intel

by io.github.rozetyp
OverviewDiscussionsAdmin

find_attack_approaches

Read-only

Find how bugs like this were actually FOUND — retrieve real disclosed bug-bounty report mechanic-cards whose approach is closest (by mechanism) to your query or a seed CVE.

The "what approach worked on a bug like this, on which program, and what did it pay" layer:
grounded in real publicly-disclosed, paid HackerOne reports, each distilled to a transferable
mechanic (bug_class / source / sink / trigger / impact) and embedded in the same space as the
corpus. Use it to BORROW a proven attack approach for a target or CVE you're working — especially
to get UNSTUCK: results are novelty-ranked to surface non-obvious moves over the common playbook.

Give EITHER:
  query:  a free-text approach/bug description, e.g. "SSRF via webhook URL to cloud metadata",
          "IDOR swapping an object id to read another tenant's data".
  cve_id: a seed CVE you're working — returns the human attack approaches that transfer to it.
Optional: bug_class filter (e.g. "SSRF") sharpens precision; days filters by disclosure recency;
  tried=["IDOR","XSS","SSRF"] = bug-classes you've ALREADY attempted, pushed down so you get the
  approaches you HAVEN'T thought of (the "I've exhausted the obvious, what else?" move).
  capec="CAPEC-664" = constrain to a canonical attack-pattern class (CAPEC). Pass it ALONE (no
  query/cve) to pull the real disclosed mechanics for that pattern, ranked by bounty — the
  coverage-driven "give me proven moves for this attack class" retrieval.
Each result carries its canonical 'capec' class(es), the transferable 'trigger', the program, the
bounty paid, and whether that program is still active/in-scope. Complements find_similar_vulns.

Input Schema

NameRequiredDescriptionDefault
daysNo
capecNo
limitNo
queryNo
triedNo
cve_idNo
bug_classNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.7/5.0
Behavior4/5

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

Annotations only cover readOnlyHint=true and openWorldHint=false, so the description adds real behavioral context: results are grounded in publicly-disclosed paid HackerOne reports, novelty-ranked to surface non-obvious moves (or bounty-ranked in capec mode), and each result reports program liveness/in-scope status. It stops short of describing pagination or result volume behavior, keeping it just below a 5.

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 core purpose and then organized into a clear query/cve block and an optional-filters block, so it is scannable. It is somewhat verbose and stylized (BORROW, UNSTUCK, quoted asides), and a few clauses restate the value proposition, but nearly every sentence carries actionable invocation detail.

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 7-parameter, no-output-schema retrieval tool, the description covers input modes, filter interactions, ranking behavior, and even the shape of returned fields (capec class, trigger, program, bounty, program liveness). Nothing an agent needs to call it correctly is missing.

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?

With 0% schema description coverage the description must carry every parameter, and it does: query (with examples), cve_id, bug_class, days, tried (with a concrete example and its push-down semantics), and capec (with an example and the solo-usage constraint). The only unmentioned param is limit, whose default of 10 is self-evident; the mutual-exclusivity rule for capec is a genuine semantic addition the schema cannot express.

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?

States a specific verb+resource: retrieving real disclosed bug-bounty mechanic-cards by mechanism similarity to a query or seed CVE. It layers the purpose precisely ('the what approach worked on a bug like this, on which program, and what did it pay layer') and explicitly positions itself as a complement to find_similar_vulns, so an agent can distinguish it from siblings 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 Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives explicit when-to-use framing ('BORROW a proven attack approach... especially to get UNSTUCK') plus concrete invocation modes: EITHER query OR cve_id, and capec 'Pass it ALONE (no query/cve)' for coverage-driven retrieval. It also names the alternative/complement (find_similar_vulns) and the exhausted-playbook scenario that selects the tried filter.

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

All vuln-intel toolsInspect
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.

Resources