Skip to main content
Glama

Niche — Editorial Intelligence

by com.nicheangle

Ingest a brand kit from a URL

niche_brand_kit_ingest

Auto-populate the user's BrandKit (palette / fonts / tagline / logo / wordmark / boilerplate / voice notes) from files, a URL, or pasted text. Additive by default: fills empty fields, leaves populated ones alone. Idempotent: re-running the same inputs doesn't double-write.

Overwrite rule: if the target brand kit already has an identity (a tagline/boilerplate/voice for a different brand), do not silently overwrite it. First ask the user whether to replace it. If the account supports multiple brand profiles, prefer creating a separate brand instead: pass a new brand_id slug plus brand_name rather than clobbering the existing one. Only pass replace=true once the user has confirmed they want this brand re-learned from the new source.

Use when the agent has brand assets in scope (a working directory with logos / press-kit / brand-guide PDFs, the user's portfolio or Substack URL, pasted boilerplate copy) and wants to populate Niche's BrandKit so future signal_scan and content generation inherit the brand context. Agent-side equivalent of the Niche web app brand-kit ingest surface, same backend engine.

Async, then poll: a URL or multi-file ingest runs in the background, so this call returns fast with {ingest_id, status:'ingesting'}. Then poll niche_brand_kit_ingest_status(ingest_id) until status is 'done'; that response carries the populated BrandKit, the ingest report (detected[] / skipped[] / errors[]), and a diff[] of changed fields. (Loop: ingest, then poll status until done/failed; same pattern as niche_signal_scan to niche_session_state.) Do not re-call ingest while one is running; a duplicate of the same inputs attaches to the in-flight job. URL ingest also fills voice primitives when the page has post-shaped text (Substack/blog/X). If a URL is slow or thin to scrape, the visual fields may land before the voice pass completes; when the report flags this, paste the page's About/homepage copy via text= to complete the brand voice.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
textNoOptional URL (homepage, Substack, portfolio, LinkedIn) or a paste of brand text (tagline, boilerplate, voice notes). URL takes precedence when both look URL-shaped.
filesNoFiles to ingest (logos, brand-guide PDFs, screenshots, color swatches, headshots). Each entry: {name, mime_type, data_base64}. The engine classifies each by image content and routes to logo/wordmark/headshot/brand-guide/color-swatch slots.
replaceNoDefault false (additive: fill empty fields only). Set true only after the user confirms they want an already-populated brand re-learned from this source; it overwrites the detected identity fields. Do not set true to silently clobber a different brand's kit; create a new brand_id instead.
brand_idNoWhich brand slot to ingest into. Omit for the default brand. Pass a slug (e.g. 'acme') to target or create a separate brand kit; do this when the default kit already belongs to another brand, so you don't merge two brands into one. If the account isn't entitled to additional brands, the call returns a clear error explaining what's needed.
brand_nameNoOptional display name when creating a new brand_id slot (e.g. 'Acme Co').

TDQS

A4.8/5.0
Behavior5/5

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

The description reveals crucial behavioral traits beyond the annotations: additive by default, idempotent re-runs, the overwrite rule, async background execution with fast initial response, polling expectations, duplicate attachment to in-flight jobs, voice primitives from URL text, and the possibility of visual fields landing before the voice pass. This is far richer than the annotations alone and directly guides agent expectations.

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 description is longer than average, but every sentence serves a distinct purpose: purpose, overwrite safety, usage context, async protocol, duplicate handling, and edge-case completion. It is front-loaded with the primary action and then logically organized into safety, usage, and async flow. It could be slightly trimmed, but for a complex, stateful, async tool the density is justified.

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?

Given the tool's complexity (multiple input types, async behavior, overwrite rules, no output schema), the description covers everything an agent needs: what the return value looks like immediately ({ingest_id, status}), how to poll via the status sibling, what the final response contains (populated BrandKit, ingest report with detected/skipped/errors, diff[]), and even niche completion actions like pasting text via text= if the voice pass fails. This is outstanding completeness.

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

Parameters4/5

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

Schema description coverage is 100%, so the base is 3. The description adds meaningful context beyond the schema: text is ambiguous (URL vs paste) but URL takes precedence when both look URL-shaped; files are classified by image content and routed to slots; replace defaults to false and must only be true after confirmation; brand_id is for targeting/creating separate brand kits with a slug; brand_name is for display when creating new slots. This adds behavioral nuance not present in the schema.

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 opens with a specific verb+resource: 'Auto-populate the user's BrandKit' and enumerates the exact fields (palette, fonts, tagline, etc.). It also clearly identifies the input sources (files, URL, pasted text) and distinguishes this from sibling tools like niche_brand_kit_ingest_status by stating that this call initiates ingestion while the status tool polls for results.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicit usage context is provided: 'Use when the agent has brand assets in scope...' and the tool is placed as the agent-side equivalent of the web app's ingest surface. The description gives clear when-not-to-use guidance via the overwrite rule, instructing to ask the user first, prefer creating a new brand_id rather than clobbering, and only set replace=true after explicit confirmation. It even names the polling sibling and compares the pattern to niche_signal_scan/niche_session_state.

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

All Niche — Editorial Intelligence toolsInspect
Try in Browser
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

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.

Resources