Skip to main content
Glama
GuardBee

@guardbee/mcp-security-proxy

Official

compliance_checker__analyze_privacy_policy

Analyze a privacy policy URL for GDPR/KVKK completeness, fetching the page and flagging missing disclosures without an API key.

Instructions

Fetch and analyze a privacy policy page for completeness against GDPR/KVKK requirements. Works without an API key.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
urlYesDirect URL to the privacy policy page (or homepage to auto-detect)

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv0.1.1

TDQS

B3.2/5.0
Behavior3/5

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

With no annotations, the description carries the full burden. It discloses one genuine behavioral trait, that no API key is required, and fetch/analyze implies a read-only network operation. It says nothing about return format, analysis depth, rate limits, or failure behavior for a non-existent/unreachable URL.

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?

Two short sentences, zero filler, with the core action and scope front-loaded ahead of the secondary access note. Every clause earns its place.

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

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

There is no output schema and no annotations, so the description is the only place to learn what the analysis yields (findings, gap list, score, framework breakdown). It never describes the return value, which is a material gap for an analysis tool whose output shape is otherwise unknowable.

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 coverage is 100% and the single url parameter is fully documented in the schema, including the homepage auto-detect behavior. The description adds no parameter syntax or format detail beyond that, so the baseline 3 for schema-documented parameters applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description names a specific verb pair (fetch and analyze) and a specific resource (privacy policy page) scoped to GDPR/KVKK completeness, which is concrete enough for an agent to know exactly what it produces. It does not, however, differentiate itself from the sibling compliance_checker__check_compliance, so the agent cannot tell the two apart from the text alone.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

There is no when-to-use or when-not-to-use guidance and no mention of the sibling alternatives (check_compliance, list_requirements, compare_frameworks). 'Works without an API key' is an access hint, not usage guidance, leaving the selection decision to inference.

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