Skip to main content
Glama

run_api_security_scan

Run OWASP API Security Top 10 rule-based scans on OpenAPI 3.x specs to detect vulnerabilities with severity ratings and remediation guidance.

Instructions

v0.8.0: OWASP API Security Top 10 (2023) rule-based scanner. Loads an OpenAPI 3.x spec, walks each path × method, and dispatches v0.8's 5 in-scope rules — BOLA (API1), Broken Authentication (API2), Mass Assignment (API3, opt-in), Function-Level Authz (API5), Security Misconfiguration (API8). Returns a v0.8 security report block with per-finding rule_id, severity (critical/high/medium/low/info), endpoint, evidence dict, and remediation_hint.

Requires QA_API_SECURITY_CONSENT=true at the server level. Non-localhost hosts must be in QA_API_SECURITY_AUTHORIZED_DOMAINS (comma-separated). mass_assignment mutates server state — opt in by passing it in categories. Tier 1 fixture (examples/sample_vulnerable_api/) ships with the package for self-tests.

v0.9.4 — Pass plan_id (from qa_plan) to auto-verify the scan's findings against the plan's critical points in the same call. The response gains a plan_verification block (per-CP checklist + overall status). One-shot equivalent of qa_plan → run_api_security_scan → verify_plan.

Returns: {scan_id, spec_url, base_url, categories_run, rules_ran, ops_scanned, severity_threshold, findings[...], summary{total, by_severity}, findings_below_threshold_count, plan_verification (only when plan_id given)}.

Error shapes: consent_required / unauthorized_domain / spec_load_failed / no_base_url / unknown_categories / bad_severity_threshold.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
spec_urlYesOpenAPI 3.x URL (http:// or https://) or local path (file:// or bare). YAML and JSON both accepted.
authNoAuth config. `token` enables single-user rules (headers + broken_auth). Add `alt_user_token` to enable two-user rules (bola + function_authz). For BOLA: also provide `bola_test_ids: {user_a: [...], user_b: [...]}` listing the ids of objects each user owns.
categoriesNoRules to run. Default: headers + broken_auth + bola + function_authz (mass_assignment excluded — it mutates server state, opt in explicitly).
severity_thresholdNoMinimum severity to include in `findings`. Lower-severity findings counted in `findings_below_threshold_count`.medium
base_urlNoOverride spec's `servers[0].url`. Use when the spec is hosted separately from the API.
timeout_sNoPer-request timeout. Default 30s.
plan_idNov0.9.4 — Optional. plan_id returned by qa_plan. When supplied, the scan auto-verifies its findings against the plan's critical points and adds a `plan_verification` block to the response (per-CP checklist + overall passed/incomplete/failed status). Only findings ABOVE severity_threshold are seen by the verifier — if a CP targets a low-severity finding, lower the threshold to 'low' or 'info' accordingly.
Behavior5/5

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

With no annotations provided, the description fully covers behavioral traits: it discloses that mass_assignment mutates server state, describes error shapes, explains severity_threshold behavior, and details return structure including plan_verification.

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 description is front-loaded with version and core purpose. It is fairly long but each sentence adds value. Minor improvements could be made to structure with bullet points, but overall it is appropriately sized.

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?

Given the tool's complexity (7 parameters, no output schema), the description provides comprehensive context: return shape, error shapes, authentication details, plan verification, version history. It leaves no critical gaps.

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 baseline is 3, but the description adds significant meaning beyond the schema, such as explaining how auth config enables different rules, default categories, and the effect of plan_id. This extra context justifies a score of 4.

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 description clearly states the tool is an OWASP API Security Top 10 rule-based scanner that loads an OpenAPI spec and runs specific rules. It distinguishes itself from sibling tools like run_tests and qa_plan by focusing on security scanning.

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 description provides context for when to use the tool and prerequisites (consent, authorized domains). It explains opt-in for mass_assignment. However, it does not explicitly state when not to use it versus alternatives like qa_plan or verify_plan.

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

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/kao273183/mk-qa-master'

If you have feedback or need assistance with the MCP directory API, please join our Discord server