Skip to main content
Glama
MCP ZAP Server

MCP ZAP Server

zap_target_import

Imports OpenAPI/Swagger definitions, GraphQL schemas, or SOAP WSDLs into a ZAP session to prepare API endpoints for authorized testing.

Instructions

Import an OpenAPI/Swagger definition, GraphQL schema, or SOAP WSDL to prepare API endpoints for testing. Use when you have an API definition; use zap_crawl_start to discover ordinary web pages. Requires a reachable, configured ZAP instance with the matching OpenAPI, GraphQL, or SOAP add-on. Import changes the current ZAP session and may send requests to the definition source and API targets; use only authorized targets. It does not start an active scan: after reviewing import messages, call zap_attack_start with the API target URL only when active testing is permitted and approved. Content mode accepts actual OpenAPI JSON/YAML text with a required full HTTP(S) hostOverride and an explicitly enabled shared filesystem; it cannot read chat attachments automatically. Returns plain text containing definition type, source kind, and import status. URL/file mode also includes source and engine messages; content mode withholds contents, internal paths, and raw engine warning text. Review warnings before proceeding. Invalid inputs, blocked URLs, and ZAP API failures raise errors.

Input Schema

NameRequiredDescriptionDefault
sourceYesRequired definition URL, ZAP-readable file path, or actual JSON/YAML text when sourceKind=content. A chat attachment name, client-local path or inaccessible resource URI is not definition content. Content imports are bounded to 1 MiB and reject external references and YAML aliases.
sourceKindYesRequired source mode: url for a definition ZAP downloads, file for a definition on ZAP's filesystem, or content for self-contained OpenAPI JSON/YAML text. Content is OpenAPI-only and requires configured shared staging. Case-insensitive.
endpointUrlNoRequired for graphql: HTTP(S) API endpoint to test, for example https://api.example.com/graphql; must be reachable by ZAP and allowed by server URL policy. Ignored for openapi and soap.
hostOverrideNoOpenAPI target override allowed by server URL policy. Required full HTTP(S) URL for content imports, for example https://api.example.com/v1. URL/file imports also allow authority/path with an explicit host, for example api.example.com:9090/v1; omit only for trusted definition-derived targets constrained by ZAP egress controls. Ignored for graphql and soap.
definitionTypeYesRequired definition format: openapi (OpenAPI/Swagger), graphql (GraphQL schema), or soap (WSDL). Case-insensitive.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed3 schema fields changedv0.16.0
    • changedInput schema / properties / hostOverride / description
      Previous value: -"Optional OpenAPI target override allowed by server URL policy: a full HTTP(S) URL or authority/path with an explicit host, for example https://api.example.com/v1 or api.example.com:9090/v1. Scheme-only and path-only overrides are rejected; use a full URL instead. Omit or leave blank only for trusted definition-derived targets constrained by ZAP egress controls. Ignored for graphql and soap."New value: +"OpenAPI target override allowed by server URL policy. Required full HTTP(S) URL for content imports, for example https://api.example.com/v1. URL/file imports also allow authority/path with an explicit host, for example api.example.com:9090/v1; omit only for trusted definition-derived targets constrained by ZAP egress controls. Ignored for graphql and soap."
    • changedInput schema / properties / source / description
      Previous value: -"Required HTTP(S) definition URL reachable by ZAP and allowed by server URL policy, or a file path readable inside the ZAP host/container (for example /zap/wrk/openapi.yaml). File contents are not accepted here."New value: +"Required definition URL, ZAP-readable file path, or actual JSON/YAML text when sourceKind=content. A chat attachment name, client-local path or inaccessible resource URI is not definition content. Content imports are bounded to 1 MiB and reject external references and YAML aliases."
    • changedInput schema / properties / sourceKind / description
      Previous value: -"Required source mode: url for a definition ZAP downloads, or file for a definition on ZAP's filesystem. Case-insensitive."New value: +"Required source mode: url for a definition ZAP downloads, file for a definition on ZAP's filesystem, or content for self-contained OpenAPI JSON/YAML text. Content is OpenAPI-only and requires configured shared staging. Case-insensitive."
  2. Changed5 schema fields changedv0.14.0
    • changedInput schema / properties / definitionType / description
      Previous value: -"Definition type: openapi, graphql, or soap"New value: +"Required definition format: openapi (OpenAPI/Swagger), graphql (GraphQL schema), or soap (WSDL). Case-insensitive."
    • changedInput schema / properties / endpointUrl / description
      Previous value: -"Optional GraphQL endpoint URL when definitionType is graphql"New value: +"Required for graphql: HTTP(S) API endpoint to test, for example https://api.example.com/graphql; must be reachable by ZAP and allowed by server URL policy. Ignored for openapi and soap."
    • changedInput schema / properties / hostOverride / description
      Previous value: -"Optional host override when definitionType is openapi"New value: +"Optional OpenAPI target override allowed by server URL policy: a full HTTP(S) URL or authority/path with an explicit host, for example https://api.example.com/v1 or api.example.com:9090/v1. Scheme-only and path-only overrides are rejected; use a full URL instead. Omit or leave blank only for trusted definition-derived targets constrained by ZAP egress controls. Ignored for graphql and soap."
    • changedInput schema / properties / source / description
      Previous value: -"Definition source URL or file path"New value: +"Required HTTP(S) definition URL reachable by ZAP and allowed by server URL policy, or a file path readable inside the ZAP host/container (for example /zap/wrk/openapi.yaml). File contents are not accepted here."
    • changedInput schema / properties / sourceKind / description
      Previous value: -"Source kind: url or file"New value: +"Required source mode: url for a definition ZAP downloads, or file for a definition on ZAP's filesystem. Case-insensitive."
  3. First observed

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 behavioral burden and does so thoroughly: it discloses prerequisites, session changes, outbound requests to definition sources and API targets, authorization constraints, content-mode limitations, return contents, and error conditions. It also clarifies that import does not start an active scan, which prevents a meaningful misuse.

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?

The description is front-loaded with purpose and usage, then covers prerequisites, side effects, content mode, return values, and errors. Despite its length, every sentence adds actionable information for a complex, multi-mode tool with no annotations.

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 no annotations and no output schema, the description is complete enough for correct invocation: it covers required environment setup, source modes, side effects, authorization constraints, return behavior, error cases, and the necessary follow-up step. Nothing critical for safe and correct use appears to be missing.

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 description coverage is 100%, and the schema already documents all five parameters in detail, including mode-specific requirements. The description restates some cross-parameter constraints, such as content mode requiring hostOverride and shared filesystem staging, but adds little semantic detail beyond what the schema provides.

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 states a specific verb and resource: importing OpenAPI/Swagger, GraphQL, or SOAP WSDL definitions to prepare API endpoints for testing. It also distinguishes this from ordinary web discovery by explicitly naming zap_crawl_start as the alternative for web pages.

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?

It gives clear selection guidance: use this when you have an API definition, but use zap_crawl_start to discover ordinary web pages. It also states the post-import workflow, directing the agent to review messages and only call zap_attack_start when active testing is permitted and approved.

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