Skip to main content
Glama
Sign In
F6 ASM MCP Server

F6 ASM MCP Server

Official
by F6-Security
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Remote

asm_assets_summary

Read-onlyIdempotent

Counts a company's assets by type, status, and issue level, with issue totals per type; large-company summaries continue in the background and return progress via job_id.

Instructions

Counts over every asset of a company, no records: by type, status and issue level (hasIssues), with assets that have issues per type. Default status: the perimeter (confirmed, new). A large company does not fit in one call: the answer then has complete=false and job_id, the rest is counted in the background, and calling again with the same arguments returns progress and then the full result (reused for ASM_SUMMARY_TTL seconds).

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_assets_summary"
  }
}

Input Schema

NameRequiredDescriptionDefault
typeNoEmpty = all types.
statusNoDefault: the perimeter ['confirmed', 'new']. Pass all three to include excluded.
company_idYesCompany id from asm_list_companies (field id), e.g. 3f2b6c1e-0000-4a5b-8c9d-0123456789ab.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A4.1/5.0
Behavior5/5

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

Annotations already declare readOnly/idempotent/non-destructive, but the description adds behavior they cannot express: oversized companies return complete=false plus a job_id, counting continues in the background, re-invoking with identical arguments yields progress and then the full result, and results are cached for ASM_SUMMARY_TTL seconds. This polling/reuse protocol is exactly the kind of information an agent needs and would otherwise discover only by trial and error.

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?

Two sentences, front-loaded with the purpose before the operational caveats about async polling and caching — a sensible ordering. The opening clause is compressed to the point of being slightly ungrammatical, and the bare ASM_SUMMARY_TTL token is unexplained, but there is little wasted text.

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?

For a three-parameter aggregation tool with no output schema, the definition covers the critical operational case (large companies, job_id polling) and the default filtering behavior. It stops short of describing the shape of the returned counts (e.g. the key names for per-type and hasIssues breakdowns), which an agent would want since no output schema exists.

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

Parameters3/5

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

Schema coverage is 100%, and the schema descriptions already carry the key semantics ('Empty = all types', default status of confirmed/new, passing all three to include excluded), including where company_id comes from. The prose largely restates the same default-status rule rather than adding new meaning, so the baseline of 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific action and scope: it counts assets for a company across type, status and issue level, and explicitly notes 'no records', which separates it from the asset-listing sibling. The phrasing 'Counts over every asset' is slightly awkward, but the aggregation intent and dimensions are unambiguous.

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?

The 'no records' clause implicitly tells the agent to use this for aggregate counts rather than record retrieval, and the large-company paragraph explains exactly what to do when the result is truncated (call again with the same arguments). It never names asm_get_assets or asm_issues_summary as the alternative for record-level or issue-only queries, so no explicit exclusion is provided.

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