Skip to main content
Glama
adsandcode

fbc-guard

by adsandcode
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

check_fbc_code

Statically checks HTML or JavaScript that writes Meta's _fbc and _fbp cookies from fbclid, catching click-ID modifications, truncation, stale IDs, and millisecond timestamp errors before deployment.

Instructions

Statically check HTML or JavaScript that reads fbclid from the URL and writes Meta's _fbc click ID cookie (and optionally _fbp). It catches the mistakes that make Meta Events Manager report a modified fbclid or attribute a conversion to the wrong ad: keeping an old click ID when a visitor arrives from a new ad, decoding, re-casing or truncating the click ID, writing creationTime in seconds instead of milliseconds, and hard-coding subdomainIndex. Rules: FBC-01: A new fbclid must overwrite an older _fbc cookie. FBC-02: Do not URL-decode fbclid a second time. FBC-03: Do not change the case of fbclid. FBC-04: Do not truncate fbclid. FBC-05: _fbc creationTime must be in milliseconds. FBC-06: Check that a hard-coded subdomainIndex matches the cookie domain. FBP-01: _fbp creationTime must be in milliseconds. Returns JSON with status ("pass", "fail", "unknown" or "not_applicable"), failed, unknown and warnings (rule IDs), and rules (one entry per rule with status "pass", "fail", "unknown" or "warn", evidence, what it protects against, severity, and a link to Meta's documentation). "unknown" means no rule failed but at least one could not decide, for example FBC-01 when it cannot tell which variable holds the fbclid from the URL. "not_applicable" means no _fbc appeared in the content, so nothing was judged. Neither is a pass. "warn" comes from a warning-level rule (FBC-06) and never changes the overall status. This is static analysis of source text, not execution: minified, bundled or obfuscated code can hide a mistake, so a pass is not proof of correctness.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
codeYesHTML or JavaScript source to check. Include every file that touches fbclid, _fbc or _fbp, concatenated.
kindNoHow to read `code`. "html": analyse the inline <script> bodies. "js": analyse it as JavaScript. "auto": HTML if it starts with "<", JavaScript otherwise.auto

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A4.3/5.0
Behavior5/5

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

With no annotations, the description carries the full burden and does so thoroughly: it explains the returned JSON shape, the meaning of `pass`, `fail`, `unknown`, `not_applicable`, and `warn`, and warns that minified, bundled, or obfuscated code can hide mistakes so a pass is not proof of correctness.

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 long but front-loaded and dense: purpose first, then the failures it catches, then rules, then return semantics and limitations. Every section adds useful selection or interpretation context, and there is no repetition or filler.

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 and no annotations, so the description must explain returns and limitations itself. It does both, including status semantics and the static-analysis caveat, leaving no major gap for an agent to call or interpret the tool correctly.

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 already defines `code` and `kind` in detail. The description does not add meaningfully more parameter-level guidance beyond what the schema provides, so the baseline of 3 is appropriate.

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 states a specific verb and resource: statically check HTML or JavaScript involving `fbclid`, `_fbc`, and optionally `_fbp`. It is clear what the tool does, but it does not explicitly distinguish itself from the sibling `check_fbc_url` or say that this tool is for source text while the sibling is for URLs.

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?

It gives clear context for use by explaining the exact Meta reporting mistakes the checker catches and by stating that this is static source analysis, not execution. It does not explicitly name `check_fbc_url` or give an exclusion rule for when to choose the sibling instead.

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