Skip to main content
Glama

sqlmap_scan

Test a URL for SQL injection vulnerabilities using SQLMap. Identify vulnerable parameters and extract database information when authorized.

Instructions

Test a URL for SQL injection vulnerabilities using SQLMap.

SQLMap automates the detection and exploitation of SQL injection flaws. This tool requires explicit authorization — SQL injection testing can cause database errors and potential data exposure.

IMPORTANT: The target URL parameter is named 'url', not 'target'. Always call this tool as: sqlmap_scan(url="http://...", ...)

Args: url: Full target URL including query string to test. MUST be named 'url' (not 'target'). Example: "http://example.com/search?q=test" method: HTTP method: GET or POST. data: POST data string (e.g. "username=admin&password=test"). parameter: Specific parameter to test (e.g. "q" or "username"). If empty, tests all parameters. headers: Additional HTTP headers as a dict (e.g. {"Authorization": "Bearer token"}). Useful for testing authenticated endpoints. level: Detection aggressiveness level (1-5). Default: 1 (safe). Levels 3+ significantly increase request count. risk: Risk of tests (1-3). Default: 1 (safe). Risk 2+ includes boolean-based tests; Risk 3 includes heavy OR-based tests. dbms: Force specific DBMS (e.g. "mysql", "postgresql", "mssql"). Leave empty for auto-detection. technique: SQLi technique(s) to test: B(oolean-blind), E(rror-based), U(nion-query), S(tacked-queries), T(ime-blind), Q(inline-queries). Can be combined: "BT" = boolean + time-blind. Default: all techniques. prefix: Injection prefix string to close the original SQL expression (e.g. "'))" for LIKE expressions like LIKE '%q%')). Crucial for complex injection points that sqlmap can't auto-detect. suffix: Injection suffix string appended after payload (e.g. "--"). tamper: Tamper script name(s) to bypass WAF/filters (e.g. "space2comment", "between,randomcase"). batch: Run in non-interactive batch mode (recommended: True). dump: Dump contents of affected database tables (requires confirmed injection). enum_tables: Enumerate database tables (--tables flag). enum_users: Enumerate database users (--users flag). enum_dbs: Enumerate available databases (--dbs flag). sql_query: Execute a custom SQL SELECT query via the injection point (e.g. "SELECT email,password FROM Users"). Useful when --tables/--dump fail due to JSON response filtering. timeout: Override scan timeout in seconds.

Returns: SQL injection test results including vulnerable parameters, DBMS info, and optionally dumped data or enumerated tables/users/databases.

Note: - Level > 2 or Risk > 2 requires careful consideration — may cause errors. - Target must be in tengu.toml [targets].allowed_hosts. - This tool requires explicit human authorization for exploitation. - dump/enum_* flags require a confirmed injection point.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
urlYes
dataNo
dbmsNo
dumpNo
riskNo
batchNo
levelNo
methodNoGET
prefixNo
suffixNo
tamperNo
headersNo
timeoutNo
enum_dbsNo
parameterNo
sql_queryNo
techniqueNo
enum_usersNo
enum_tablesNo

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

Behavior5/5

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

With no annotations provided, the description carries full burden and does so thoroughly. It clearly discloses that SQLMap automates detection and exploitation, can cause database errors and data exposure, requires explicit authorization, and notes that higher level/risk values increase request counts. It also explains dump/enum effects and target restrictions.

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 long but well-structured with Args, Returns, and Note sections. Each parameter explanation is concise and informative. Front-loaded summary gives immediate clarity, and no sentence is wasted. The length is justified by the 19-parameter tool.

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 complexity (19 params, high-risk exploitation tool), the description is complete. It covers purpose, authorization, target restrictions, parameter details, return values, and safety warnings. The presence of an output schema means return values need not be elaborated, but the Returns section still provides useful context.

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?

Schema description coverage is 0%, so the description must explain all parameters. It does: every parameter (url, method, data, parameter, headers, level, risk, dbms, technique, prefix, suffix, tamper, batch, dump, enum_*, sql_query, timeout) is described with purpose, example, or consequence. This far exceeds the bare schema and fully compensates for the lack of schema descriptions.

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 opens with a clear statement: 'Test a URL for SQL injection vulnerabilities using SQLMap.' This identifies the specific action (test), the resource (URL), and the tool (SQLMap), distinguishing it from sibling tools like xss_scan or commix_scan. The scope and intent are immediately clear.

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 strong usage guidance: explicit authorization is required, targets must be in allowed_hosts, and level/risk warnings are given. It does not name alternative tools or explicitly state when not to use it, but the context is clear. This falls just short of a 5 because it lacks explicit 'when-not' or alternative comparisons.

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/rfunix/tengu'

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