CrunchJunkie

create_client

Create a client (brand/domain) in the 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 the plan's client cap. Prompts are added afterwards with add_tracking_prompt. Requires MCP write actions; without confirm:true it returns a preview.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "name": "<name>"
    },
    "name": "create_client"
  }
}

Input 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 the 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 the 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.

Changed6 schema fields changedOct 24, 2026
- changedInput schema / $schema
```
Previous value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"
```
- removedInput schema / additionalProperties
```
Removed value: -false
```
- addedInput schema / properties / brandAliases / propertyNames
```
Added value: +{
+  "type": "string"
+}
```
- addedInput schema / properties / competitorDomains / propertyNames
```
Added value: +{
+  "type": "string"
+}
```
- removedInput schema / properties / profile / additionalProperties
```
Removed value: -false
```
- addedInput schema / properties / runsPerPrompt / maximum
```
Added value: +9007199254740991
```

Changed2 schema fields changedOct 22, 2026

changedInput schema / properties / language / description

Previous value: -"Answer language, ISO 639-1. Default: the market's usual language, else your account's language."New value: +"Answer language, ISO 639-1. Default: the market's usual language, else the account's language."

changedInput schema / properties / runsPerPrompt / description

Previous value: -"Passes per prompt per scan (default 2; clamped to your plan's ceiling)."New value: +"Passes per prompt per scan (default 2; clamped to the plan's ceiling)."

First observedOct 19, 2026

TDQS

A4.1/5.0

Behavior4/5

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

Annotations already declare non-read-only, non-destructive, closed-world. The description adds meaningful behavior beyond them: the plan's client cap, the write-permission requirement, and the two-step preview-then-confirm flow with a 15-minute one-time previewToken. It doesn't spell out what the preview contains or what the success response looks like, but for a create tool this is solid.

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?

The main sentence is long but front-loaded with the core action and default behavior, followed by two short sentences covering sequencing and the preview requirement. Dense yet every clause carries information; the parameter enumeration is the only mildly redundant part.

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 20-parameter, nested-object creation tool with no output schema, the description covers the essentials an agent needs: required outcome, cap, permissions, and the preview/confirm gate. What is missing is a note on what the preview returns and how to proceed from it, which the previewToken param description partially fills.

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 every parameter is already documented with defaults and constraints. The description enumerates the parameter categories (brand facts, target attributes, competitors, market, language, engines, passes per prompt), which aids orientation, but adds little syntax or default detail beyond the schema. Baseline 3 is appropriate.

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?

Specific verb + resource ('Create a client (brand/domain) in the workspace') plus scope: it also creates the AI-visibility project by default. It explicitly notes prompts are added separately via add_tracking_prompt, which cleanly separates it from that sibling.

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?

States the operational precondition ('Requires MCP write actions') and the preview/confirm workflow, and points to add_tracking_prompt for the follow-up step. It does not explicitly say when not to use it (e.g. vs update_project_settings or list_clients for pre-checks), but the context is clear.

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?