Skip to main content
Glama
Sign In
F6 ASM MCP Server

F6 ASM MCP Server

Official
by F6-Security
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Remote

asm_get_issues

Read-onlyIdempotent

Retrieves a company's security issues with filters for severity, status, category, asset, port, and CVE, using a resume cursor for paginated results.

Instructions

Issues (security findings) of a company: POST /api/v2/issues/updated, oldest-first, following the seqUpdate cursor. Filters: severity, status, category, test_name, asset, port, issue_hash, cve. Status and severity are re-checked locally because the server filter leaks. Returns items with complete, reason and seqUpdate; when complete is false, call again with seq_update. One call stops at max_items, after ~40 s or at 1 MB. For totals use asm_issues_summary; for proof of one issue asm_get_issue_evidence.

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": {
      "company_id": "<company_id>"
    },
    "name": "asm_get_issues"
  }
}

Input Schema

NameRequiredDescriptionDefault
cveNoCVE ids, e.g. CVE-2024-6387.
portNoPorts, e.g. [22, 3389].
assetNoIssues of these assets (domain, IP).
fieldsNoReturn only these fields, dotted paths allowed, e.g. ['alertHash', 'alertSeverity', 'alertStatus', 'testName', 'alertBody.asset', 'alertBody.reason'].
statusNoEmpty = every status. Open issues = ['detected', 'under review'].
compactNoDefault true: drop heavy and repeated fields (whois/DNS of domains, discovery graph, descriptions, company fields). false returns records as the API sent them.
categoryNoe.g. Vulnerabilities, Network Security, DNS & Domains.
severityNocrit / high / medium / low. In records they read as alertSeverity Crit / Error / Warning / Low and alertBody.status 'Critical severity' / 'High severity' / ...
max_itemsNoInteger, 1-5000, default 200: stop after this many issues.
page_sizeNoRecords per API request, at most 2000. A page that times out is retried at half the size automatically.
test_nameNoExact test names, e.g. 'CVE vulnurability', 'Insecure Network Headers', 'Remote management open port: 22'.
company_idYesCompany id from asm_list_companies (field id), e.g. 3f2b6c1e-0000-4a5b-8c9d-0123456789ab.
issue_hashNoSpecific issues by id (alertHash).
seq_updateNoResume cursor: the seqUpdate of a previous answer of this tool with the same filters. Omit to start from the oldest record. Saved after a full walk, it returns only what changed since.
sort_by_first_seenNoOrder by first detection instead of last update.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A4.4/5.0
Behavior3/5

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

Annotations already declare readOnly/idempotent/non-destructive/openWorld, so the safety profile is covered. The description nevertheless adds substantial behavior: status and severity are re-checked locally because the server filter leaks, a call stops at max_items / ~40 s / 1 MB, and timed-out pages are retried at half size. Not a contradiction, but it does not describe the return payload shape beyond three field names.

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

Conciseness5/5

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

Front-loaded with resource and ordering, then filters, then the cursor/stop semantics, then sibling routing. Dense but every clause carries operational meaning; no filler sentences.

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

Completeness4/5

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

With 15 parameters and no output schema, the definition supplies the essential return contract (items with complete, reason, seqUpdate) and the pagination loop, which is what an agent needs to call it correctly. It stops short of enumerating the returned fields' meaning, but the fields param and sibling evidence tool cover most of that gap.

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; the description still earns a bump by explaining behaviors the schema does not, notably the ~40 s / 1 MB stop condition and that max_items bounds a single call rather than the whole result set. Filter names largely repeat the schema, keeping it a step below the top.

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 and resource plus scope: issues (security findings) of a company, oldest-first by seqUpdate cursor. It distinguishes itself in one line from asm_issues_summary (totals) and asm_get_issue_evidence (proof of one issue).

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?

Explicit routing to alternatives: 'For totals use asm_issues_summary; for proof of one issue asm_get_issue_evidence.' Also gives the resume condition ('when complete is false, call again with seq_update') and notes the saved-cursor behavior after a full walk.

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

Deploy Server

Other Tools