Skip to main content
Glama

Server Details

Audit creator scripts for TikTok Shop and Amazon policy violations. Returns flags and safe rewrites.

Ownership verified
Status
Healthy
Last Tested
Transport
Streamable HTTP
URL
Repository
NimishRangani/banproof-mcp
GitHub Stars
0
Server Listing
banproof-mcp

Available Tools

2 tools
audit_scriptAudit script for policy violationsA
Read-onlyIdempotent
Inspect

Audit a TikTok Shop or Amazon affiliate video script for policy violations. Detects: medical claims, guarantees, false certifications, unproven efficacy, urgency/scarcity language, fake social proof, income claims, and missing FTC disclosures (#ad/#sponsored). Returns flagged phrases, reasons, safe rewrites, and an overall risk level.

ParametersJSON Schema
NameRequiredDescriptionDefault
scriptYesThe full video script text to audit.
product_urlNoOptional: URL of the product page being promoted. When provided, the script is cross-checked against the actual product claims — overclaims are flagged as additional violations.

TDQS

A4.1/5.0
Behavior4/5

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

Annotations already declare readOnlyHint=true and idempotentHint=true, so the description does not need to restate safety. It adds useful behavioral detail by listing what it detects and what it returns. Minor omissions like advisory nature or non-exhaustiveness are not critical given the annotation coverage.

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 efficient and well-structured: it opens with the core action, then lists detection categories, then states the output. Every sentence carries useful information and there is no filler or repetition of schema/annotation data.

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?

There is no output schema, but the description covers the key return values (flagged phrases, reasons, safe rewrites, risk level). Combined with 100% parameter coverage and read-only/idempotent annotations, the agent has enough information to invoke the tool correctly and understand its results.

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%, so the schema fully documents `script` and `product_url`. The description does not add parameter-level meaning beyond the schema, which matches the baseline expectation for full schema coverage.

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 names a specific verb ('Audit'), a concrete resource ('TikTok Shop or Amazon affiliate video script'), and enumerates the exact violation categories it detects. It also states the return values, making the tool's purpose unmistakable even without opening the schema or comparing to siblings.

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

Usage Guidelines3/5

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

The usage context is implied: an agent can infer this tool should be used when a video script needs a policy-compliance check. However, it does not explicitly state when not to use it, nor does it mention the sibling tool generate_appeal or how the two relate.

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

generate_appealGenerate platform violation appealAInspect

Generate a ready-to-submit appeal response for a TikTok, Amazon, or YouTube policy violation notice. Stays within TikTok's 800-character appeal limit. Paste the violation notice text you received and specify the platform.

ParametersJSON Schema
NameRequiredDescriptionDefault
platformYesThe platform that issued the violation: tiktok, amazon, or youtube.
violation_noticeYesThe full text of the violation notice or strike you received from the platform.

TDQS

A4.2/5.0
Behavior4/5

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

Annotations are minimal negative hints, so the description carries most of the behavioral burden. It adds meaningful behavior by stating the output is 'ready-to-submit' and that it respects TikTok's 800-character limit. It does not promise appeal success or introduce any contradiction with the annotations.

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 two concise sentences, front-loaded with the tool's purpose and followed by the key constraint and input instructions. Every sentence earns its place with no filler or redundant detail.

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 two-parameter generation tool with no output schema, the description covers the purpose, the required inputs, and an important length constraint. It lightly implies rather than states the output format, but this is a minor gap given the low complexity and complete schema.

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%, so the baseline is 3. The description adds only surface-level guidance ('Paste the violation notice text... specify the platform') that mostly restates what the schema already documents. It does not introduce new parameter semantics.

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 states a specific verb ('Generate') and a clear resource ('a ready-to-submit appeal response for TikTok, Amazon, or YouTube policy violation notice'). It is easy to distinguish from the sibling audit_script because the purpose is explicit and scoped to three named platforms.

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 gives clear usage context: paste the received violation notice and specify the platform. It provides the triggering condition for use without naming alternatives or exclusions, but the sibling tool is unrelated enough that exclusions are not needed here.

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

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.

  1. 2 tool updates
    • Changedaudit_script1 field changed
      • addedInput schema / properties / product_url
        Added value: +{
        +  "description": "Optional: URL of the product page being promoted. When provided, the script is cross-checked against the actual product claims — overclaims are flagged as additional violations.",
        +  "format": "uri",
        +  "type": "string"
        +}
    • Addedgenerate_appeal
  2. 1 tool update
    • First observedaudit_script

Frequently Asked Questions

Discussions

No comments yet. Be the first to start the discussion!

Related MCP Connectors

Related MCP Servers

  • A
    license
    A
    quality
    B
    maintenance
    Checks AI-generated social media and ad content against current policies of 8 major platforms, flagging risky phrases and providing compliant rewrites to prevent account restrictions.
    1
    207
    MIT
  • A
    license
    A
    quality
    C
    maintenance
    Provides AI agents with structured short-form content mechanics including hooks, script structures, retention strategies, and CTAs, along with auditing tools to avoid common posting failures.
    7
    61
    MIT
Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A4.2/5.0
Disambiguation5/5

The two tools have completely distinct purposes: audit_script analyzes content for violations, while generate_appeal creates responses to violation notices. There is no overlap or ambiguity between them.

Naming Consistency5/5

Both tool names follow the same verb_noun pattern: audit_script and generate_appeal. The naming is clear, consistent, and predictable.

Tool Count3/5

With only 2 tools, the server feels thin for its stated purpose of 'ban-proofing.' While each tool is useful, the scope likely warrants additional tools such as rewrite_script or check_policy to fully support the workflow.

Completeness4/5

The audit tool covers policy violations and provides safe rewrites, and the appeal tool handles violation notices. Minor gaps exist (e.g., no tool to directly submit appeals or access policy details), but the core workflow of identify-and-appeal is covered.