AgentPixel

Configure consent and policy

configure_consent

Destructive

Turn on and set up the consent bar for a pixel.

Changing any setting makes a new policy version, and returning visitors are asked again. Returns the policy link and the script tag to put on the site.

Input Schema

TableJSON Schema

Name	Required	Description
`pixel_id`	Yes	pixel_id of the pixel to configure. Example: px_7a1b2c3d4e5f6a7b
`purposes`	Yes	What the consent bar asks the visitor to allow. One or more of: analytics, resolution, newsletter, email_sharing, phone_sharing, partner_email, partner_calls, partner_sms. Include resolution, or no visitor is ever identified. Example: ["resolution", "analytics"]
`data_sharing`	No	Optional. true if the site owner shares consented contact data with other parties, false if not. Shown in the hosted notice. Example: false
`controller_name`	Yes	Name of the business or person that owns the site. It is shown in the consent bar as the party asking the visitor for permission. 1 to 200 characters. Example: Example Shop LLC
`controller_type`	No	Optional. One of company, person or organization. Describes the site owner in the hosted notice. Example: company
`site_policy_url`	No	Optional. HTTPS address of the site's own privacy policy. The bar links to it, and the hosted notice becomes a short add-on about identification. Leave empty to use the hosted notice on its own. Example: https://shop.example.com/privacy
`contact_channels`	No	Optional. How the site owner may contact a visitor who consents. Any of: email, phone, sms, agentic. Example: ["email"]
`disclosed_parties`	No	Optional. Names of the other parties the site owner wants the hosted notice to list, one name per item. Example: ["Example CRM Inc."]
`controller_contact`	No	Optional. Email address or web address where visitors can reach the site owner about their data. Shown in the hosted notice. Example: privacy@example.com
`controller_jurisdiction`	No	Optional. Where the site owner is based, as plain text, such as a country or US state. Shown in the hosted notice. Example: Florida, USA

Output Schema

TableJSON Schema

Name	Required	Description	Default
`snippet`	Yes
`pixel_id`	Yes
`purposes`	Yes
`policy_url`	Yes
`policy_hash`	Yes
`policy_version`	Yes
`consent_enabled`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Changed10 schema fields changedOct 10, 2026

addedInput schema / properties / contact_channels / description

Added value: +"Optional. How the site owner may contact a visitor who consents. Any of: email, phone, sms, agentic. Example: [\"email\"]"

addedInput schema / properties / controller_contact / description

Added value: +"Optional. Email address or web address where visitors can reach the site owner about their data. Shown in the hosted notice. Example: privacy@example.com"

addedInput schema / properties / controller_jurisdiction / description

Added value: +"Optional. Where the site owner is based, as plain text, such as a country or US state. Shown in the hosted notice. Example: Florida, USA"

addedInput schema / properties / controller_name / description

Added value: +"Name of the business or person that owns the site. It is shown in the consent bar as the party asking the visitor for permission. 1 to 200 characters. Example: Example Shop LLC"

addedInput schema / properties / controller_type / description

Added value: +"Optional. One of company, person or organization. Describes the site owner in the hosted notice. Example: company"

addedInput schema / properties / data_sharing / description

Added value: +"Optional. true if the site owner shares consented contact data with other parties, false if not. Shown in the hosted notice. Example: false"

addedInput schema / properties / disclosed_parties / description

Added value: +"Optional. Names of the other parties the site owner wants the hosted notice to list, one name per item. Example: [\"Example CRM Inc.\"]"

changedInput schema / properties / pixel_id / description

Previous value: -"Exact pixel_id returned by create_pixel or list_pixels; never an account ID"New value: +"pixel_id of the pixel to configure. Example: px_7a1b2c3d4e5f6a7b"

addedInput schema / properties / purposes / description

Added value: +"What the consent bar asks the visitor to allow. One or more of: analytics, resolution, newsletter, email_sharing, phone_sharing, partner_email, partner_calls, partner_sms. Include resolution, or no visitor is ever identified. Example: [\"resolution\", \"analytics\"]"

addedInput schema / properties / site_policy_url / description

Added value: +"Optional. HTTPS address of the site's own privacy policy. The bar links to it, and the hosted notice becomes a short add-on about identification. Leave empty to use the hosted notice on its own. Example: https://shop.example.com/privacy"

Changed12 schema fields changedOct 9, 2026

addedInput schema / additionalProperties
```
Added value: +false
```

changedInput schema / properties / contact_channels / anyOf

Previous value: -[
-  {
-    "items": {
-      "type": "string"
-    },
-    "type": "array"
-  },
-  {
-    "type": "null"
-  }
-]New value: +[
+  {
+    "items": {
+      "enum": [
+        "email",
+        "phone",
+        "sms",
+        "agentic"
+      ],
+      "type": "string"
+    },
+    "type": "array"
+  },
+  {
+    "type": "null"
+  }
+]

addedInput schema / properties / controller_name / maxLength
```
Added value: +200
```
addedInput schema / properties / controller_name / minLength
```
Added value: +1
```

addedInput schema / properties / pixel_id / description

Added value: +"Exact pixel_id returned by create_pixel or list_pixels; never an account ID"

addedInput schema / properties / pixel_id / maxLength
```
Added value: +80
```
addedInput schema / properties / pixel_id / minLength
```
Added value: +1
```
addedInput schema / properties / pixel_id / pattern
```
Added value: +"^[A-Za-z0-9_-]+$"
```

addedInput schema / properties / purposes / items / enum

Added value: +[
+  "analytics",
+  "resolution",
+  "newsletter",
+  "email_sharing",
+  "phone_sharing",
+  "partner_email",
+  "partner_calls",
+  "partner_sms"
+]

addedInput schema / properties / purposes / maxItems
```
Added value: +8
```
addedInput schema / properties / purposes / minItems
```
Added value: +1
```

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "additionalProperties": true,
+  "properties": {
+    "consent_enabled": {
+      "title": "Consent Enabled",
+      "type": "boolean"
+    },
+    "pixel_id": {
+      "title": "Pixel Id",
+      "type": "string"
+    },
+    "policy_hash": {
+      "title": "Policy Hash",
+      "type": "string"
+    },
+    "policy_url": {
+      "title": "Policy Url",
+      "type": "string"
+    },
+    "policy_version": {
+      "title": "Policy Version",
+      "type": "integer"
+    },
+    "purposes": {
+      "items": {
+        "enum": [
+          "analytics",
+          "resolution",
+          "newsletter",
+          "email_sharing",
+          "phone_sharing",
+          "partner_email",
+          "partner_calls",
+          "partner_sms"
+        ],
+        "type": "string"
+      },
+      "title": "Purposes",
+      "type": "array"
+    },
+    "snippet": {
+      "title": "Snippet",
+      "type": "string"
+    }
+  },
+  "required": [
+    "pixel_id",
+    "consent_enabled",
+    "policy_version",
+    "policy_hash",
+    "policy_url",
+    "snippet",
+    "purposes"
+  ],
+  "title": "Consent",
+  "type": "object"
+}

First observedOct 9, 2026

TDQS

A3.9/5.0

Behavior4/5

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

Annotations only declare destructiveHint=true and idempotentHint=false; the description adds genuinely useful behavior: every settings change spawns a new policy version and re-prompts returning visitors, and the call returns a policy link plus an embed script tag. It stops short of stating what is destroyed or whether an existing bar is overwritten, so it does not fully cover the destructive hint.

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?

Three short sentences, front-loaded with the action and followed by the side effect and return value. The return-value sentence slightly duplicates what the output schema already conveys, but it is not wasteful enough to penalize more heavily.

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?

With a full output schema and complete parameter documentation, the description only needs to carry the behavioral load, and it does flag the versioning/re-consent consequence. It is nearly complete, lacking only a note on whether an existing consent bar is replaced or what destructive means here.

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 all 10 parameters are already documented with examples and constraints in the schema. The description adds no parameter-level meaning (syntax, required-vs-optional tradeoffs, purpose interactions), so the baseline of 3 applies.

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?

States a specific verb and resource ('turn on and set up the consent bar for a pixel'), which is clearly distinguishable from siblings like get_policy, get_pixel, and create_pixel. An agent can tell this is the configuration mutation, not a read of existing policy state.

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?

Usage is implied by the setup context ('turn on and set up'), but there is no explicit when-to-use guidance or routing against alternatives such as get_policy for inspecting an existing configuration. The agent must infer that this is the write path when no policy exists yet.

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

All AgentPixel tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.