AgentPixel

Start 30-day trial

signup_free

Start a 30-day trial, no card. After that, $1 per account per month for 3 pixels and 500 new contacts per UTC calendar month.

    Sends a 6-digit code to the email address. Returns account_id and signup_token; keep both.
    Next: ask the person for the 6-digit code in the AgentPixel email, then call confirm_signup(account_id, code, signup_token).
    The signup_token lasts 24 hours.

Input Schema

TableJSON Schema

Name	Required	Description
`code`	No	Optional trial code from a directory or listing, such as SMITHERY60. An unknown code never blocks signup. Example: GLAMA60
`email`	Yes	Email address of the person who will own the account. The 6-digit code is sent here. Ask the person for it; never invent or guess an address. Example: pat@example.com
`display_name`	Yes	Name shown on the account, such as the person's name or the business name. 1 to 200 characters. Example: Pat Lee

Output Schema

TableJSON Schema

Name	Required	Description	Default
`plan`	Yes
`status`	Yes
`account_id`	Yes
`signup_token`	Yes
`email_verified`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Changed3 schema fields changedOct 10, 2026

addedInput schema / properties / code

Added value: +{
+  "anyOf": [
+    {
+      "maxLength": 40,
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "description": "Optional trial code from a directory or listing, such as SMITHERY60. An unknown code never blocks signup. Example: GLAMA60",
+  "title": "Code"
+}

addedInput schema / properties / display_name / description

Added value: +"Name shown on the account, such as the person's name or the business name. 1 to 200 characters. Example: Pat Lee"

addedInput schema / properties / email / description

Added value: +"Email address of the person who will own the account. The 6-digit code is sent here. Ask the person for it; never invent or guess an address. Example: pat@example.com"

Changed7 schema fields changedOct 9, 2026

addedInput schema / additionalProperties
```
Added value: +false
```
addedInput schema / properties / display_name / maxLength
```
Added value: +200
```
addedInput schema / properties / display_name / minLength
```
Added value: +1
```
addedInput schema / properties / email / maxLength
```
Added value: +254
```
addedInput schema / properties / email / minLength
```
Added value: +3
```

addedInput schema / properties / email / pattern

Added value: +"^[^\\s@]+@[^\\s@]+\\.[^\\s@]+$"

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "additionalProperties": true,
+  "properties": {
+    "account_id": {
+      "title": "Account Id",
+      "type": "string"
+    },
+    "email_verified": {
+      "title": "Email Verified",
+      "type": "boolean"
+    },
+    "plan": {
+      "title": "Plan",
+      "type": "string"
+    },
+    "signup_token": {
+      "title": "Signup Token",
+      "type": "string"
+    },
+    "status": {
+      "title": "Status",
+      "type": "string"
+    }
+  },
+  "required": [
+    "account_id",
+    "status",
+    "plan",
+    "signup_token",
+    "email_verified"
+  ],
+  "title": "Signup",
+  "type": "object"
+}

First observedOct 9, 2026

TDQS

A4.1/5.0

Behavior4/5

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

Annotations declare readOnlyHint=false, idempotentHint=false, openWorldHint=true and destructiveHint=false, so the mutation profile is already known. The description adds genuinely useful context beyond that: no card required, the price after the trial, that an email code is dispatched, and that signup_token expires in 24 hours. It does not warn whether re-invoking creates a duplicate account, which is the main behavioral gap.

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?

Front-loads the offer and price, then the mechanics, then the required next call, then the token lifetime. Every sentence carries information, though the pricing sentence is longer than strictly needed for tool selection.

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?

An output schema exists, yet the description still names the returned account_id and signup_token and tells the agent to keep both, plus the exact signature of the next call and the token TTL — a complete happy-path flow. It omits error/duplicate-account handling and never mentions resend_code as the recovery path for a lost code.

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 all three parameters (including the optional trial code) are already documented with patterns, lengths and examples. The description only reinforces that the 6-digit code goes to the email address; it adds no format or constraint detail beyond the schema, so the baseline 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+resource with commercial terms ('Start a 30-day trial, no card... $1 per account per month'), which instantly distinguishes it from sibling signup-adjacent tools like confirm_signup and resend_code. An agent can tell what this does and what it costs without opening the schema.

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?

Explicitly prescribes the follow-up flow: ask the person for the emailed 6-digit code, then call confirm_signup(account_id, code, signup_token). That is strong sequencing guidance, but it never says when NOT to use this tool (e.g. when an account already exists, in which case whoami/setup_status would be the right entry point), so there are no exclusions.

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.