Skip to main content
Glama

Set brand profile

niche_brand_profile_set

Set or update the persisted brand profile for a brand. The profile is a structured JSON document applied across every pipeline stage: voice rules, banned terms, canonical vocabulary, framing allowlist, channel config, compliance disclosures, and verifier overrides. Use it to persist a profile derived from a repo or docs so future runs inherit the rules, or to update voice rules and banned terms before the next run.

Required sections: identity and voice (a profile with no voice falls back to generic drafts). A re-set that omits voice is accepted with a default voice stub rather than rejected.

Validation: tiered lints (error / warn / info). 'error' lints reject the set; 'warn' lints accept with a note. The response includes lints[]. conflicts[] lists fields locked by the brand kit, which takes precedence; those profile values are not stored.

brand_id is unique per user; re-setting the same brand_id replaces the prior profile.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
profileYesThe brand profile JSON. Schema sections (each drives a pipeline stage): identity (who the brand is), audience (who it's for), voice (register/rhythm/lexicon rules the copy obeys), lexicon (canonical_terms plus banned_terms the verifier enforces), framing (frame slugs from Niche's editorial taxonomy; pass `allowed` and/or `blocked` as lists of slugs. The set is closed: an unrecognized frame rejects the set and the error returns the valid slugs, so nothing is silently dropped), structure (default article shapes), offers (what the creator sells: {product, what_it_is, proof_point?, cta, link}; lands signal-led posts on the offer), verifier_overrides (truthfulness thresholds), channels (per-platform config), source_quality (trusted/blocked domains), compliance (required disclosures), metadata. Fill the load-bearing ones (identity / voice / lexicon / framing / verifier_overrides) for a strong profile; the rest are optional. A malformed set returns a `template` of the full schema with inline field docs in the error response, so no separate discovery call is needed.
brand_idYesUnique-per-user identifier for this brand (e.g. 'acme', 'acme-blog'). Stored as a string; lowercase kebab-case recommended.
schema_versionNoProfile schema version. Defaults to '1.0'.1.0

TDQS

A4.8/5.0
Behavior5/5

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

The description extensively discloses behavior beyond the annotations: re-setting replaces prior profile, validation uses tiered lints (error/warn/info), conflicts with brand kit are not stored, missing voice falls back to a default stub, and malformed sets return a template. This far exceeds the minimal readOnly/destructive hints.

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 appropriately so for a complex tool with nested objects. It is front-loaded with the core purpose, then logically organized into required sections, validation, and brand_id semantics. Every sentence adds actionable information without fluff.

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?

With no output schema, the description compensates by disclosing the response format (lints[], conflicts[], template) and edge-case behaviors (default voice stub, brand kit precedence). It covers all necessary operational context for a complex setter tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% and the description adds substantial meaning: profile structure details (identity, voice, lexicon, framing, verifier_overrides, etc.), encoding of closed framing set behavior, error response with valid slugs, and the template return on malformed sets. brand_id format and uniqueness are also clarified.

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?

The description explicitly states 'Set or update the persisted brand profile for a brand' with a clear verb and resource. It enumerates the pipeline stages the profile applies to, distinguishing it from sibling tools like niche_brand_profile_get and niche_brand_kit_update. The scope is unambiguous.

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?

The description provides clear context for when to use the tool: 'persist a profile derived from a repo or docs so future runs inherit the rules, or to update voice rules and banned terms before the next run.' It does not explicitly name alternatives or exclusion criteria, but the usage context is well-defined.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A4.2/5.0
Disambiguation4/5

Tools are mostly distinct across the pipeline—discovery, brand setup, drafting, rendering, publishing, session management—and descriptions are detailed. Minor overlap exists between niche_signal_scan and niche_intelligence_query (both discovery) and between niche_add_output and niche_draft_create (both generate outputs), but the descriptions clearly differentiate them. Overall, an agent can reliably select the right tool.

Naming Consistency3/5

All tools share the `niche_` prefix and snake_case, but the verb/noun order is inconsistent: some are verb-first (add_output, render_image_card, list_sessions) while many are noun-first (angle_propose, brand_kit_ingest, draft_create, session_cancel). This mixed convention requires the agent to learn each name individually rather than predict the pattern.

Tool Count3/5

25 tools is on the heavy side but appropriate for the platform's scope—full editorial intelligence from discovery to publish. No redundant tools, and each covers a distinct aspect, but the count is high enough that it feels dense and may require orientation (which niche_whoami addresses).

Completeness4/5

The toolset covers the full workflow: discovery, angle proposal, drafting, revision, publishing, rendering, asset attachment, brand setup, and session management. Minor gaps exist, such as no direct read tool for the current BrandKit (only via ingest status) and no hard-delete tool (session_cancel mentions the REST endpoint instead), but these are edge cases and agents can work around them.