Skip to main content
Glama
Jambozx

OnlineCyberTools MCP (280+ filterable tools)

security_htaccess_generator

Read-onlyIdempotent

Generate Apache .htaccess file text for security, redirects, caching, compression, and access control using structured options. No file writing; returns the text for copying.

Instructions

Apache .htaccess Generator. Build the text of an Apache 2.4+ .htaccess file from structured options, then return it as a string for you to copy or save - it does NOT deploy, write, or touch any file on any server. Assembles named directive groups on demand: force HTTPS (mod_rewrite), www/non-www canonicalisation, mod_alias path redirects (301/302/303/307/308), custom mod_rewrite rules, IP allow/deny access control (Order/Deny/Allow, IPv4+CIDR / IPv6), custom ErrorDocument pages, GZIP (mod_deflate) and Brotli (mod_brotli) compression, mod_expires + mod_headers browser-cache lifetimes, directory-listing toggle, Referer hotlink protection, and free-form appended rules. Use security_csp_generator for Content-Security-Policy headers, security_robots_txt_generator for robots.txt, or linux_web_server_config_generator for full Apache/Nginx/Caddy vhost configs. Set operation to "presets" to list ready-made configurations instead of generating. Runs locally via a sandboxed compiled module: read-only, non-destructive, c

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
operationYes"generate" builds .htaccess text from the options below; "presets" ignores all options and returns the curated preset list.generate
forceHttpsNoEmit a mod_rewrite block that 301-redirects every HTTP request to HTTPS.
wwwModeNoCanonical host: force the www subdomain, force the bare apex, or emit no host-canonicalisation rule.leave-alone
redirectsNomod_alias path-prefix redirects. Empty from/to, self-redirects, and homepage catches raise warnings.
rewritesNoCustom mod_rewrite rules. Pattern is regex-compiled for a warning check (Apache uses PCRE).
denyIpsNoIPv4/IPv6 addresses or CIDR ranges to block (Deny from). Invalid entries still emit but raise a warning.
allowIpsNoIPv4/IPv6 addresses or CIDR ranges to allow; when set alone, everyone else is denied.
errorPagesNoMap of HTTP status code (400-599, as string key) to ErrorDocument path, e.g. 404 to /404.html.
gzipNoEmit a mod_deflate GZIP AddOutputFilterByType block for text/JS/CSS/JSON.
brotliNoEmit a mod_brotli compression block (typically 15-25% smaller than gzip).
cacheHeadersNomod_expires + mod_headers cache lifetimes. Omit or use 0 to skip a tier.
directoryListingNoAutoindex: disabled emits Options -Indexes, enabled emits Options +Indexes, leave-alone emits nothing.leave-alone
hotlinkProtectionNoReferer-based image hotlink protection via mod_rewrite.
customRulesNoFree-form Apache directives appended verbatim at the end of the file.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
successNoWhether the request succeeded.
operationNoThe operation performed (generate or presets).
resultNoFor operation=generate: the generated file and metadata. For operation=presets: a presets array.
Behavior5/5

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

Annotations already indicate read-only, non-destructive, idempotent. The description reinforces that it does not touch any server files and runs locally in a sandbox. No contradictions.

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 a single paragraph that front-loads the core purpose and lists features comprehensively. While slightly dense, it is still relatively concise and well-structured.

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 (14 params, nested objects, output schema), the description covers purpose, behavior, parameter details, warnings, and alternatives. It is complete.

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?

Despite 100% schema coverage, the description adds valuable context beyond schema, such as warnings for self-redirects, explanations of wwwMode values, and compression size comparisons.

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 generates Apache .htaccess text from structured options and returns it as a string, emphasizing it does not deploy or write files. It lists many features and distinguishes from sibling tools like security_csp_generator.

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?

Explicitly tells when to use this tool versus alternatives (e.g., 'Use security_csp_generator for Content-Security-Policy headers'). Also explains the 'presets' operation for listing ready-made configurations.

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/Jambozx/onlinecybertools-mcp-server'

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