Skip to main content
Glama
Sign In
operant-mcp

operant-mcp

Official
by operantlabs
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

frame_buster_bypass

Test sandbox attribute bypass for JavaScript frame busters. Generates PoC HTML that uses iframe sandbox='allow-forms' to disable JavaScript execution while allowing form submission for clickjacking.

Instructions

Test sandbox attribute bypass for JavaScript frame busters. Generates PoC HTML that uses iframe sandbox='allow-forms' to disable JavaScript execution (neutralizing frame-busting code) while still allowing form submission for clickjacking. Also checks if the target page contains common frame-busting patterns. Returns: {frame_buster_detected, patterns_found, sandbox_poc_html}. Side effects: Single GET request to detect frame-busting code.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "target_url": "<target_url>"
    },
    "name": "frame_buster_bypass"
  }
}

Input Schema

NameRequiredDescriptionDefault
target_urlYesURL that uses JavaScript frame-busting code

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.0.0

TDQS

A4.2/5.0
Behavior4/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 well by disclosing key behaviors: it makes a single GET request, generates PoC HTML, checks for common patterns, and returns specific data structure. It doesn't mention rate limits, authentication needs, or potential side effects beyond the GET request.

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 efficiently structured in two sentences: first explains the tool's function and mechanism, second details the return values and side effects. Every element serves a purpose with zero wasted words.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

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 annotations and no output schema, the description provides good completeness: explains what the tool does, how it works, what it returns, and side effects. It could benefit from more detail about the returned data structure or example patterns, but covers the essential context well.

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% for the single parameter 'target_url', so the schema already documents it adequately. The description adds context about what kind of URL (one with JavaScript frame-busting code) but doesn't provide additional syntax or format details 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 clearly states the specific action ('Test sandbox attribute bypass for JavaScript frame busters') and resource (target URL with frame-busting code). It distinguishes from siblings by focusing on frame-buster bypass techniques rather than other security tests like clickjacking_test or xss_reflected_test.

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 implies usage context (testing JavaScript frame-busting code) but doesn't explicitly state when to use this tool versus alternatives like clickjacking_test or other bypass methods. It provides clear functional context but lacks explicit comparison or exclusion guidance.

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

Deploy Server

Other Tools