Allows routing scan traffic through Burp Suite to integrate with existing web security testing workflows and proxy analysis.
Provides specialized testing and detection for SQL injection vulnerabilities in MySQL database systems.
Provides specialized testing and detection for SQL injection vulnerabilities in PostgreSQL database systems.
Provides specialized testing and detection for SQL injection vulnerabilities in SQLite database systems.
Utilizes Unicode encoding as a bypass technique to circumvent Web Application Firewalls (WAF) during security testing.
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@SQL Injection MCP Server scan http://testsite.com/products.php?id=10 for SQL injection vulnerabilities"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
A Model Context Protocol (MCP) server for discovering SQL injection vulnerabilities in web applications.
Multiple Injection Types: Error-based, Time-based, Boolean-based, Union-based, Blind SQL injection
Database Support: MySQL, MSSQL, PostgreSQL, Oracle, SQLite
HTTP Methods: GET and POST parameter testing
Authentication: Custom headers, cookies, Bearer tokens
Proxy Support: Route traffic through Burp Suite or other proxies
WAF Bypass: URL encoding, Hex encoding, Unicode, Case swapping, Comment injection
Custom Payloads: Load payloads from external files
Related MCP server: operant-mcp
# Using uv (recommended)
cd SQLinjector_MCP
uv sync
# Using pip
pip install -e .# Using uv
uv run sqli-mcp
# Or directly
python -m sqli_mcp.serverAdd to your MCP configuration:
{
"mcpServers": {
"sqli-scanner": {
"command": "uv",
"args": ["--directory", "C:/path/to/SQLinjector_MCP", "run", "sqli-mcp"]
}
}
}Configure the server URL after starting with HTTP transport:
uv run python -c "from sqli_mcp.server import mcp; mcp.run(transport='streamable-http')"Then connect to http://localhost:8000/mcp
Tool | Description |
| Full URL scan for SQLi in all detected parameters |
| Test specific GET parameter |
| Test specific POST parameter |
| Test a single payload against a target |
| List available built-in payloads |
| Load payloads from external file |
| Get WAF bypass variants of a payload |
| Retrieve previous scan results |
Bulk Scanning | |
| Scan multiple URLs (newline-separated, up to 500) |
| Scan URLs from a file (one per line) |
| Retrieve batch scan results |
| Get only vulnerable URLs from batch |
Use scan_url with:
- target_url: "http://vulnerable-site.com/page?id=1"Use scan_post_parameter with:
- target_url: "http://site.com/login"
- post_data: "username=admin&password=test"
- parameter: "username"
- cookies: "session=abc123"
- bearer_token: "your-jwt-token"Use scan_url with:
- target_url: "http://target.com/page?id=1"
- proxy_url: "http://127.0.0.1:8080"
- verify_ssl: falseUse scan_url with:
- target_url: "http://target.com/page?id=1"
- waf_bypass: "comment_injection"Scan multiple URLs from a list:
Use scan_urls_batch with:
- urls: "http://site1.com/page?id=1
http://site2.com/search?q=test
http://site3.com/user?uid=5"
- concurrency: 10
- waf_bypass: "url_encode"Scan URLs from a file:
Use scan_urls_from_file with:
- file_path: "C:/path/to/urls.txt"
- concurrency: 5
- proxy_url: "http://127.0.0.1:8080"Get vulnerable URLs only:
Use get_vulnerable_urls with:
- batch_id: "abc12345"Create a text file with one payload per line:
# my_payloads.txt
' OR '1'='1
" OR "1"="1
' UNION SELECT NULL--Then load with:
Use load_custom_payloads_from_file with:
- file_path: "C:/path/to/my_payloads.txt"
- injection_type: "union_based"
- name: "my_custom"⚠️ This tool is intended for authorized security testing only. Always obtain proper authorization before testing any system for vulnerabilities. Unauthorized access to computer systems is illegal.
MIT
Continue scanning remaining URLs from a previous batch. Use this when scan_urls_batch returns has_more=True.
Args: batch_id: Batch ID from a previous scan_urls_batch call
Returns: Next batch of scan results
| Name | Required | Description | Default |
|---|---|---|---|
| batch_id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description bears full responsibility for behavioral disclosure. It describes the return type but does not specify side effects, idempotency, or error handling (e.g., invalid batch_id).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two concise sentences plus an Args block, all relevant and necessary. No redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple continuation tool with one parameter, the description covers purpose, usage, parameter, and return value. No output schema is present but the return type is mentioned. Complete for the tool's complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The only parameter 'batch_id' is explained in the Args section as 'Batch ID from a previous scan_urls_batch call', adding meaningful context beyond the schema which only specifies type and requirement.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Continue scanning remaining URLs from a previous batch.' It uses a specific verb and resource, and distinguishes from the 'scan_urls_batch' sibling which initiates a new batch.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit condition for use is provided: 'Use this when scan_urls_batch returns has_more=True.' This gives clear guidance, though alternative tools like 'get_batch_result' are not mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Retrieve a previous batch scan result by ID.
Args: batch_id: Batch ID from a previous batch scan
Returns: Batch scan result details
| Name | Required | Description | Default |
|---|---|---|---|
| batch_id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description indicates a read-only retrieve operation, but with no annotations provided, it lacks details on error handling, idempotency, rate limits, or other behavioral traits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded, with a clear main line followed by structured Args and Returns sections, containing no superfluous content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple retrieval tool with one parameter and no output schema, the description covers the basic usage and input source, though it omits error handling details. It is adequate given the complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema coverage, the description compensates by explaining the batch_id parameter as 'Batch ID from a previous batch scan,' adding meaningful context beyond the schema's type definition.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Retrieve a previous batch scan result by ID,' using a specific verb and resource, and distinguishes from siblings like get_scan_result.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage after a batch scan by indicating the batch_id comes from a previous batch scan, but it does not explicitly state when to use this tool versus alternatives or provide exclusion criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Retrieve a previous scan result by ID.
Args: scan_id: Scan ID from a previous scan
Returns: Scan result details
| Name | Required | Description | Default |
|---|---|---|---|
| scan_id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must fully disclose behavioral traits. It only states 'Retrieve' (implying a read operation) but does not specify what happens if scan_id is invalid, whether there are rate limits, or any side effects. This is insufficient for full transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, with the first sentence stating the primary purpose. The docstring format adds some structure, though it repeats information already in the schema. No unnecessary sentences.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter tool with no output schema, the description covers the basic purpose adequately. However, it lacks behavioral context and does not describe the return value in detail, leaving some gaps for the agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage, so the description must compensate. The 'Args' section adds meaning by stating 'Scan ID from a previous scan', clarifying the source of the ID. However, it does not provide format constraints or examples, which would be helpful.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Retrieve' and resource 'previous scan result by ID', distinguishing it from sibling tools like continue_batch or get_batch_result which have different purposes. This makes the tool's purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives such as get_batch_result or get_vulnerable_urls. The description only states the basic function, leaving the AI agent to infer usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get only the vulnerable URLs from a batch scan.
Args: batch_id: Batch ID from a previous batch scan
Returns: List of vulnerable URLs with their scan details
| Name | Required | Description | Default |
|---|---|---|---|
| batch_id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided; description carries burden. It indicates a read-only operation (get) returning a list, but lacks explicit safety notes (e.g., read-only, auth requirements). Not contradictory.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three short sentences, front-loaded with the main purpose. No unnecessary words; every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple retrieval tool with one parameter and no output schema, the description covers purpose, argument, and return type. Lacks detail on result structure and prerequisites, but adequate for basic use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds context that batch_id is from a previous batch scan, which the schema lacks (coverage 0%). However, no format or constraints are explained.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Get only the vulnerable URLs from a batch scan,' specifying the verb, resource, and source. It distinguishes from siblings like get_batch_result, though not explicitly.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies use after a batch scan via the batch_id argument, but does not provide explicit when-to-use or alternatives. No guidance on when not to use this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get all WAF bypass variants of a payload.
Args: payload: Original SQL injection payload
Returns: Dictionary of bypass techniques and their encoded payloads
| Name | Required | Description | Default |
|---|---|---|---|
| payload | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description does not disclose behavioral traits beyond the basic operation. It does not mention whether the tool is read-only, requires authentication, has rate limits, or any side effects. The return type is mentioned but not the exact structure or potential errors.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded with the main purpose. However, the docstring format (Args/Returns) adds structure but is slightly redundant given the brevity. It is efficient overall.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with one parameter and no output schema, the description provides the essential information: what it does and what the input is. However, it lacks details on output format, usage examples, or edge cases, making it minimally complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description adds minimal value by labeling the parameter as 'Original SQL injection payload'. This clarifies the expected input type but does not provide format details or constraints.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves WAF bypass variants of a given payload, with a specific verb and resource. It distinguishes from siblings like 'list_payloads' by focusing on bypass variants, though the term 'WAF bypass variants' could be more explicitly defined.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives such as 'test_payload' or 'list_payloads'. The description lacks any context about optimal use cases or filters.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List available SQL injection payloads.
Args: category: Filter by category (error_based, time_based, boolean_based, union_based, blind) database: Filter by database type (mysql, mssql, postgresql, oracle, sqlite, generic) limit: Maximum number of payloads to return
Returns: List of available payloads with descriptions
| Name | Required | Description | Default |
|---|---|---|---|
| category | No | ||
| database | No | ||
| limit | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description is the sole source. It mentions return type but does not disclose side effects, auth requirements, or rate limits. The read-only nature is not explicitly stated.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded with purpose. The docstring format is efficient, though it could be slightly more compact.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Adequately describes the tool's function given sibling tools. However, it lacks explanation of how the returned payloads integrate with scanning tools (e.g., test_payload). No output schema, but the description of return value is sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Despite 0% schema coverage, the description adds meaningful information: enum values for category and database, and a default for limit. This 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.
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states it lists SQL injection payloads with filtering options. However, it does not differentiate from sibling tools like get_waf_bypass_payloads, which could cause confusion.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives like get_waf_bypass_payloads or load_custom_payloads_from_file. The description implies filtering usage but lacks when-not-to-use context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Load custom SQL injection payloads from a file.
Args: file_path: Absolute path to the payload file (one payload per line) injection_type: Injection type for loaded payloads database_type: Database type for loaded payloads name: Name to cache the payloads under for later use
Returns: Information about loaded payloads
| Name | Required | Description | Default |
|---|---|---|---|
| file_path | Yes | ||
| injection_type | No | error_based | |
| database_type | No | generic | |
| name | No | custom |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses that payloads are cached under a given name, but does not detail side effects like file access requirements or error handling. With no annotations, transparency is moderate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, structured with Args and Returns sections, and contains no unnecessary words. Every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has no output schema, but the description only vaguely mentions 'Information about loaded payloads'. It does not cover error cases or return format, leaving completeness moderate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Despite 0% schema description coverage, the description adds meaning for all parameters: file_path (absolute path, one per line), injection_type, database_type, and name (for caching). This compensates well for the schema's lack of descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool loads custom SQL injection payloads from a file. It uses a specific verb-resource combination, distinguishing it from siblings like list_payloads or test_payload.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives. The description lacks explicit usage context, prerequisites, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Test a specific GET parameter for SQL injection.
Args:
target_url: Target URL (e.g., http://example.com/page?id=1&name=test)
parameter: Specific parameter name to test (e.g., id)
injection_types: Comma-separated injection types to test
database_types: Comma-separated database types to test
headers: Custom headers as key:value pairs separated by |
cookies: Cookies as key=value pairs separated by ;
bearer_token: Bearer token for Authorization header
proxy_url: Proxy URL (e.g., http://127.0.0.1:8080 for Burp Suite)
verify_ssl: Verify SSL certificates
waf_bypass: WAF bypass technique
Returns: Scan results for the specified parameter
| Name | Required | Description | Default |
|---|---|---|---|
| target_url | Yes | ||
| parameter | Yes | ||
| injection_types | No | ||
| database_types | No | ||
| headers | No | ||
| cookies | No | ||
| bearer_token | No | ||
| proxy_url | No | ||
| verify_ssl | No | ||
| waf_bypass | No | none |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description outlines the parameters and returns scan results, but lacks warnings about potential side effects, authorization needs, or rate limits. Given no annotations, it partially fulfills the burden but misses safety context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a clear one-liner followed by Args and Returns sections. It is concise yet informative, though slightly longer than necessary.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the 10 parameters and mentions return type, but lacks detail on output structure and lacks guidance on prerequisites or post-conditions. For a moderately complex tool, it is adequate but not fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description adds significant value by explaining each parameter with examples and format hints (e.g., 'key:value pairs separated by |'). However, it does not enumerate valid values for injection_types or database_types.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Test a specific GET parameter for SQL injection,' specifying the verb (test), resource (GET parameter), and scope (specific parameter). It effectively distinguishes from sibling tools like scan_post_parameter and scan_url.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no explicit guidance on when to use this tool versus alternatives. It does not mention when not to use it or suggest other tools for scanning whole URLs or POST parameters.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Test a specific POST parameter for SQL injection.
Args: target_url: Target URL post_data: POST body data as key=value pairs separated by & (e.g., username=admin&password=test) parameter: Specific parameter name in POST data to test injection_types: Comma-separated injection types to test database_types: Comma-separated database types to test headers: Custom headers as key:value pairs separated by | cookies: Cookies as key=value pairs separated by ; bearer_token: Bearer token for Authorization header proxy_url: Proxy URL for Burp Suite or other proxies verify_ssl: Verify SSL certificates waf_bypass: WAF bypass technique
Returns: Scan results for the specified POST parameter
| Name | Required | Description | Default |
|---|---|---|---|
| target_url | Yes | ||
| post_data | Yes | ||
| parameter | Yes | ||
| injection_types | No | ||
| database_types | No | ||
| headers | No | ||
| cookies | No | ||
| bearer_token | No | ||
| proxy_url | No | ||
| verify_ssl | No | ||
| waf_bypass | No | none |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full responsibility. It states the tool tests for SQL injection but does not disclose that it sends potentially malicious payloads, which could trigger alarms or have legal implications. Important behavioral traits (e.g., network requests, authentication needs, side effects) are omitted.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-organized in a docstring format with clear sections for Args and Returns. It front-loads the core purpose. Although slightly verbose due to repeated formatting notes (e.g., 'key=value pairs separated by...'), it remains readable and structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (11 parameters, no output schema), the description lacks critical context: the return format is only 'Scan results' without details; no guidance on sibling tool differences; no warning about the tool's potential destructive or intrusive nature. For a security scanning tool, this is a significant gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It provides explanations for all 11 parameters (e.g., 'target_url: Target URL', 'post_data: POST body data as key=value pairs separated by &'). While some descriptions are terse, they add significant meaning beyond the schema's basic titles.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Test a specific POST parameter for SQL injection,' using a specific verb and resource. It distinguishes from siblings like 'scan_get_parameter' and 'scan_url' which target GET parameters or full URLs.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for testing a POST parameter for SQL injection, but does not provide explicit guidance on when to use this tool versus alternatives (e.g., scan_get_parameter, scan_urls_batch) or any prerequisites. It lacks when-not-to-use or alternative recommendations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Scan a URL for SQL injection vulnerabilities in all detected parameters.
Args: target_url: Target URL with query parameters to scan (e.g., http://example.com/page?id=1) method: HTTP method - GET or POST post_data: POST data as key=value pairs separated by & (e.g., username=admin&password=test) injection_types: Comma-separated injection types to test (error_based, time_based, boolean_based, union_based, blind) database_types: Comma-separated database types to test (mysql, mssql, postgresql, oracle, sqlite, generic) headers: Custom headers as key:value pairs separated by | (e.g., X-Custom:value|X-API-Key:abc123) cookies: Cookies as key=value pairs separated by ; (e.g., session=abc123;token=xyz) bearer_token: Bearer token for Authorization header proxy_url: Proxy URL for Burp Suite or other proxies (e.g., http://127.0.0.1:8080) verify_ssl: Verify SSL certificates (set to false when using proxy) waf_bypass: WAF bypass technique (none, url_encode, double_url_encode, hex_encode, unicode, case_swap, comment_injection) timeout: Request timeout in seconds delay_threshold: Delay threshold in seconds for time-based detection
Returns: Scan results with vulnerabilities found
| Name | Required | Description | Default |
|---|---|---|---|
| target_url | Yes | ||
| method | No | GET | |
| post_data | No | ||
| injection_types | No | ||
| database_types | No | ||
| headers | No | ||
| cookies | No | ||
| bearer_token | No | ||
| proxy_url | No | ||
| verify_ssl | No | ||
| waf_bypass | No | none | |
| timeout | No | ||
| delay_threshold | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description covers many behavioral aspects like injection types, WAF bypass, proxy, and timeouts. However, it omits disclosing that scanning sends potentially intrusive requests to the target, which is a significant behavioral trait.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a clear purpose first, then parameter documentation. It is slightly verbose with a vague 'Returns' line, but overall efficient for a 13-parameter tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Input parameters are thoroughly documented, but the return value is minimally described as 'Scan results with vulnerabilities found'. Given no output schema, more detail on the result format would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description provides full parameter documentation. Each parameter includes explanation and examples, e.g., 'target_url: Target URL with query parameters to scan (e.g., http://example.com/page?id=1)'. This far exceeds the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Scan a URL for SQL injection vulnerabilities in all detected parameters' which is a specific verb+resource. It distinguishes from siblings like scan_get_parameter and scan_post_parameter which focus on individual parameters.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies that this tool scans all parameters of a URL, contrasting with sibling tools that scan specific parameters. However, it does not explicitly state when to use this vs. alternatives, nor provide when-not-to-use conditions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Scan multiple URLs for SQL injection vulnerabilities in batch. Use quick_mode=True (default) for faster scans that won't timeout.
Args: urls: Newline-separated list of URLs to scan method: HTTP method - GET or POST injection_types: Comma-separated injection types (default: error_based only in quick_mode) database_types: Comma-separated database types (default: generic,mysql in quick_mode) headers: Custom headers as key:value pairs separated by | cookies: Cookies as key=value pairs separated by ; bearer_token: Bearer token for Authorization header proxy_url: Proxy URL for Burp Suite or other proxies verify_ssl: Verify SSL certificates waf_bypass: WAF bypass technique concurrency: Number of concurrent scans (1-10, default 3) timeout: Request timeout in seconds per URL (default 5) quick_mode: Use quick scan with fewer payloads (default True, recommended for many URLs) max_urls_per_batch: Max URLs to scan in one call (default 10, use continue_batch for more)
Returns: Batch scan results. If more URLs remain, use continue_batch with the batch_id.
| Name | Required | Description | Default |
|---|---|---|---|
| urls | Yes | ||
| method | No | GET | |
| injection_types | No | ||
| database_types | No | ||
| headers | No | ||
| cookies | No | ||
| bearer_token | No | ||
| proxy_url | No | ||
| verify_ssl | No | ||
| waf_bypass | No | none | |
| concurrency | No | ||
| timeout | No | ||
| quick_mode | No | ||
| max_urls_per_batch | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided; description covers concurrency, timeout, and quick_mode defaults but does not disclose potential destructive impact (SQL injection probing), auth requirements, or error behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured with a clear opening and bulleted parameter list, though slightly longer than necessary (9 lines).
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers input comprehensively and mentions batching continuation, but lacks details on return format and error handling. Output schema is absent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema coverage, the description thoroughly explains every parameter including format and defaults, far exceeding the baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states it scans multiple URLs for SQL injection vulnerabilities in batch, distinguishing it from single-URL tools like scan_url and from file-based scan_urls_from_file.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides guidance on quick_mode for faster scans and mentions continue_batch for more URLs, but lacks explicit when-not-to-use compared to siblings like scan_url or test_payload.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Scan multiple URLs from a file for SQL injection vulnerabilities. Returns results in chunks to avoid timeouts. Use continue_batch to get more results.
Args: file_path: Absolute path to file containing URLs (one URL per line) method: HTTP method - GET or POST injection_types: Comma-separated injection types to test database_types: Comma-separated database types to test headers: Custom headers as key:value pairs separated by | cookies: Cookies as key=value pairs separated by ; bearer_token: Bearer token for Authorization header proxy_url: Proxy URL for Burp Suite or other proxies verify_ssl: Verify SSL certificates waf_bypass: WAF bypass technique concurrency: Number of concurrent scans (1-10, default 3) timeout: Request timeout in seconds per URL (default 5) quick_mode: Use quick scan with fewer payloads (default True) max_urls_per_batch: Max URLs to scan in one call (default 10)
Returns: Batch scan results. If more URLs remain, use continue_batch with the batch_id.
| Name | Required | Description | Default |
|---|---|---|---|
| file_path | Yes | ||
| method | No | GET | |
| injection_types | No | ||
| database_types | No | ||
| headers | No | ||
| cookies | No | ||
| bearer_token | No | ||
| proxy_url | No | ||
| verify_ssl | No | ||
| waf_bypass | No | none | |
| concurrency | No | ||
| timeout | No | ||
| quick_mode | No | ||
| max_urls_per_batch | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It explains chunked results and continuation, but fails to disclose whether the scan is passive/active, if it can trigger WAF alerts, or any destructive potential. The safety profile (e.g., rate limiting, impact on target systems) is not addressed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a brief intro, a key usage hint (batching/continue_batch), and a clear list of arguments. Every sentence adds value and is front-loaded. No redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 14 parameters, no annotations, and no output schema, the description provides necessary parameter details and continuation guidance. However, it fails to describe the output structure (e.g., batch_id, result format), which is critical for an agent to process results. Behavioral gaps further reduce completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage, so the description's Args section adds essential meaning: file_path requires absolute path, method specifies GET/POST, etc. It also includes defaults. However, some parameters (e.g., injection_types, waf_bypass) lack valid values or examples, which would improve clarity.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it scans multiple URLs from a file for SQL injection vulnerabilities, distinguishing it from single-URL or manual input tools. However, it does not explicitly differentiate from sibling tools like scan_urls_batch, which may also handle multiple URLs but without a file.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description mentions batching and the continue_batch tool for retrieving more results, providing some guidance on usage flow. However, it lacks explicit when-to-use or when-not-to-use guidance compared to alternative scanning tools (e.g., scan_url, scan_urls_batch), and does not mention prerequisites like file permissions or access.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Test a specific SQL injection payload against a target.
Args: target_url: Target URL payload: SQL injection payload to test parameter: Parameter to inject the payload into method: HTTP method (GET or POST) post_data: POST data if method is POST headers: Custom headers as key:value pairs separated by | cookies: Cookies as key=value pairs separated by ; bearer_token: Bearer token for Authorization header proxy_url: Proxy URL for Burp Suite verify_ssl: Verify SSL certificates waf_bypass: WAF bypass technique to apply to payload
Returns: Test result with response details
| Name | Required | Description | Default |
|---|---|---|---|
| target_url | Yes | ||
| payload | Yes | ||
| parameter | Yes | ||
| method | No | GET | |
| post_data | No | ||
| headers | No | ||
| cookies | No | ||
| bearer_token | No | ||
| proxy_url | No | ||
| verify_ssl | No | ||
| waf_bypass | No | none |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Description implies the tool sends a payload and returns response details, but lacks disclosure of side effects, permissions required, or what constitutes a successful test. Annotations are absent, so description carries full burden but is only moderately transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loaded with purpose, then lists parameters in a consistent format. Slightly lengthy due to many parameters, but each line is informative and necessary.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers parameters well but lacks usage context, return value details beyond 'response details', and does not mention prerequisites or warnings. Given complexity and no annotations, more context would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, description adds substantial value by explaining parameter formats (e.g., headers as key:value pairs separated by |, cookies as key=value separated by ;) and clarifying purposes like WAF bypass technique.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states this tool tests a specific SQL injection payload against a target, distinguishing it from sibling tools that perform scans or retrieve results.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives, no mention of when not to use, and no differentiation from other scanning tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
v1.0.0continue_batchget_batch_resultget_scan_resultget_vulnerable_urlsget_waf_bypass_payloadslist_payloadsload_custom_payloads_from_filescan_get_parameterscan_post_parameterscan_urlscan_urls_batchscan_urls_from_filetest_payloadEach tool has a clearly distinct purpose: scanning single URLs/parameters, batch scanning, retrieving results, managing payloads, and testing specific payloads. No two tools are ambiguous in their function.
All tools follow a consistent verb_noun naming pattern (e.g., scan_url, list_payloads, get_scan_result). No mixing of casing or irregular verbs.
13 tools is well-scoped for a SQL injection scanning server, covering scanning, batch operations, result retrieval, payload management, and custom payload loading without being excessive.
The tool set covers the full scanning lifecycle: single/batch scanning, parameter-specific testing, result retrieval, payload management, and WAF bypass. Minor gap: no tool for clearing or aggregating results beyond batch retrieval.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Security scanner for MCP servers. Detect vulnerabilities, prompt injection, and tool poisoning.
Security, SEO and AI-visibility scanner for web apps · free scans and focused checks via MCP.
Zero-config MCP security scanner for AI-generated apps. 25K+ vulnerability patterns.
Cybersecurity MCP server for URL scanning, threat intelligence, and domain reputation.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/vivashu27/SQLinjector_MCP'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
