CrunchJunkie

create_client

Create a client (brand/domain) in your workspace and, by default, its AI-visibility project in one step — brand name, product type, Brand Profile, target attributes, brand facts, competitors (with optional domains/aliases), market, answer language, engines and passes per prompt. Respects your plan's client cap. Prompts are added afterwards with add_tracking_prompt. Requires MCP write actions; without confirm:true it returns a preview.

Input Schema

TableJSON Schema

Name	Required	Description
`name`	Yes	Client name as shown in the workspace (e.g. the company name).
`label`	No	Optional short label/segment shown on the client card.
`market`	No	Market/country, ISO 3166-1 alpha-2 (e.g. "de"). Omit or null = worldwide.
`models`	No	Engines to scan, by id (default: the Balanced preset).
`confirm`	No	Set true to apply. Omit for a preview. With confirm:true, also pass the preview's previewToken.
`profile`	No	Brand Profile free-text fields (how the brand describes itself); steers prompt suggestions.
`website`	No	The client's primary website (https://…). Used for crawlability, favicon and the GEO audit.
`language`	No	Answer language, ISO 639-1. Default: the market's usual language, else your account's language.
`brandName`	No	The brand name mentions are matched against (default: the client name).
`brandFacts`	No	Declared factual claims to fact-check against what AI says (max 15, 200 chars each).
`competitors`	No	Competitor brand names to track (they set the Share-of-Voice denominator). Max 150.
`contactName`	No	Report recipient's name (greets them in sent emails).
`productType`	No	What the brand sells, e.g. "SEO agency".
`aiVisibility`	No	Create the AI-visibility project too (default true). false = client only.
`brandAliases`	No	Canonical brand name → alternate spellings counted as the same brand (works for the client's own brand too).
`contactEmail`	No	Prefilled recipient of one-time / scheduled report emails.
`previewToken`	No	With confirm:true: the previewToken from this tool's preview (valid 15 minutes, once, for exactly the previewed arguments).
`runsPerPrompt`	No	Passes per prompt per scan (default 2; clamped to your plan's ceiling).
`targetAttributes`	No	Attributes the brand WANTS to be known for (max 20).
`competitorDomains`	No	Competitor name → website domain, e.g. { "Acme": "acme.com" }.

Schema Changelog

Changes observed during successful MCP inspections.

First observedOct 19, 2026

TDQS

A4.4/5.0

Behavior5/5

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

Goes well beyond the annotations by disclosing the auth requirement (MCP write actions), the preview/confirm token flow, and the plan client-cap constraint. These are exactly the behavioral traits an agent needs before invoking a write tool.

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 core verb and the default AI-visibility behavior, then adds constraints and the preview rule. The first sentence is dense with a long parameter enumeration, but there is no filler and each sentence carries distinct information.

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?

For a 20-parameter write tool with nested objects and no output schema, the description covers purpose, sequencing, auth, plan limits, and the preview confirmation mechanics. Nothing essential for correct invocation is missing.

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 documents all 20 parameters in detail. The description enumerates the major ones (name, product type, profile, competitors, market, language, engines, passes) but adds no format or semantics beyond what the schema already provides, so 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 (create) and resource (client / brand / domain) plus the default side effect of also creating the AI-visibility project. It distinguishes itself from the prompt-management siblings and is unambiguous 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?

Gives clear workflow context: prompts come afterwards via add_tracking_prompt, the plan's client cap applies, and the confirm:true vs preview behavior. It stops short of naming any alternative for creation (none exists), but the operational guidance is strong.

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

All CrunchJunkie 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.

Resources

Need Help?