Read niche briefings, research news, and explore sourced story angles with your assistant.
Scored across 8 tools
Two scan tools, niche_signal_scan and niche_intelligence_query, both initiate a fresh scan and require polling of niche_session_state. Their descriptions differentiate them (one takes a niche description, the other an analyst question), but an agent could still struggle to choose. Other tools are mostly distinct.
All tools use a consistent 'niche_' prefix and snake_case. The second part mostly follows a noun_verb pattern (angle_propose, feed_read, signal_scan), but list_sessions and whoami deviate slightly. Still readable and largely predictable.
Eight tools is well within the typical 3-15 range for a niche intelligence service. Each tool covers a distinct operation (scan, read, sessions, angles, orientation), so no tool feels redundant or missing in count.
The surface covers the full lifecycle: orientation (whoami), session management (list, state, cancel), scanning (signal_scan, intelligence_query), reading briefings (feed_read), and angle proposal. A minor gap is the absence of a tool to follow/unfollow a niche, though that may be handled outside the assistant interface.
Angles on one story (Pro): up to a few distinct stances a reader could take, each with a hook, the take, and the sources that support it. Pass the session_id from a scan and a story_id from its slate. Nothing is written for you; the angles are starting points.
| Name | Required | Description | Default |
|---|---|---|---|
| lens | No | Optional direction for a regenerated angle set, such as focus on the evidence. | |
| story_id | Yes | id from niche_session_state.stories[].id | |
| regenerate | No | Request another set of angles after the selected story's angles are ready. Subject to the account's allowance. | |
| session_id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint=false, openWorldHint=false, destructiveHint=false, so safety is largely covered. The description adds that this is generative drafting rather than final copy ('Nothing is written for you'), but it omits that the call consumes an account allowance and can be re-run/regenerated, and the phrase 'nothing is written' sits awkwardly against readOnlyHint=false.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three short sentences, front-loaded with what the tool returns, then the required inputs, then a caveat. No repetition of the title or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description does the work of sketching the return shape (hook, take, sources), which is the key thing an agent needs. The remaining gap is cost/allowance behavior for regenerate, which is only hinted at in the schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 75% (session_id lacks a schema description), and the description compensates by explaining where both ids come from — a scan session and its slate story. lens and regenerate are already documented in the schema, so the description's added value is the id-sourcing linkage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb (propose) and resource (angles on one story) and precisely defines the artifact produced: distinct stances, each with a hook, the take, and supporting sources. The 'one story' scope plus the (Pro) gate separates it from siblings like niche_signal_scan and niche_session_state without needing to name them.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives explicit prerequisites — 'Pass the session_id from a scan and a story_id from its slate' — which tells the agent the tool is used downstream of a scan. It also sets expectations about the output ('the angles are starting points'). No named alternatives or when-not-to-use case, so it falls short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read the latest or a dated briefing for a niche: stories, reporting dates, source links, why each story matters, and new or continuing status. Use a slug from https://nicheangle.com/n or a custom niche's URL, such as founders or ai-leaders. Assistant access requires Pro. This reads an existing briefing without starting a scan. A quiet briefing has status=quiet; no_edition means no briefing is available; unknown_niche means the slug was not found.
| Name | Required | Description | Default |
|---|---|---|---|
| date | No | Optional edition date, YYYY-MM-DD. Default: the latest edition. | |
| niche | Yes | Niche slug, e.g. financial-advisors. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=false, so the safe-read profile is covered. The description adds genuinely behavioral context beyond that: it is non-mutating ('without starting a scan'), it requires a Pro entitlement, and it defines the three degraded outcomes (quiet, no_edition, unknown_niche) an agent must be able to interpret.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loaded with the core action and return contents, then prerequisites and status codes. Every sentence carries information, though the final status-code enumeration is packed into a dense single sentence rather than separated, which slightly hurts scannability.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description takes on the burden of describing returns and does so well, listing the story fields and the sentinel status values. For a two-parameter read tool with full annotation coverage this is close to complete; the only real omission is any note on pagination or edition-count limits.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3, but the description goes beyond the schema by explaining where a valid slug originates (site URL or custom niche URL) and giving additional examples ('founders', 'ai-leaders') not present in the schema's single example. The date parameter's default-latest behavior is restated from the schema rather than extended, so it is not a full 5.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('Read the latest or a dated briefing for a niche') and enumerates the payload (stories, reporting dates, source links, why each story matters, status). It also explicitly separates itself from the scan sibling with 'This reads an existing briefing without starting a scan,' so an agent can route correctly without opening other schemas.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives concrete input provenance ('a slug from https://nicheangle.com/n or a custom niche's URL, such as founders or ai-leaders'), a default behavior ('latest' unless a date is given), and a precondition ('Assistant access requires Pro'). It stops short of naming niche_signal_scan explicitly as the alternative when the user wants fresh data, so the contrast is implied rather than stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Ask an analyst-shaped question over a fresh scan of a niche (Pro): 'the biggest developments this week', 'what is emerging', 'where money is moving'. Returns the sourced slate plus a short synthesis when requested. Returns a session_id; poll niche_session_state until cp1_awaiting_story. For synthesis, continue polling with wait_until=synthesis and wait=30 until it arrives or a shortfall is reported.
| Name | Required | Description | Default |
|---|---|---|---|
| lens | No | mainstream covers established reporting, emerging emphasizes newer topics, and investment focuses on funding developments. | |
| count | No | Requested number of developments, from 3 to 15. The result can contain fewer when reporting is limited. | |
| window | No | Reporting window: 24h, week, month, quarter, or year. Pair with recency_strict for a hard cutoff. | |
| subject | Yes | The subject/space to investigate (2-200 chars). Specific is better. | |
| synthesis | No | none returns stories only. narratives adds sourced themes across the stories. patterns adds a summary of broader developments. Default none. | |
| recency_strict | No | Exclude reporting outside the requested window. Default false; strict windows can return fewer stories. | |
| source_quality | No | strict prioritizes well-supported stories; balanced is the default; broad includes less-established reporting. Inspect the returned sources before relying on a claim. | balanced |
| idempotency_key | No | Optional stable key for retries of the same scan, so a retry reuses the original run. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations mark this as non-read-only and open-world but say nothing about the async lifecycle; the description fills that gap by disclosing the session_id return, the cp1_awaiting_story checkpoint, the synthesis polling loop, and the possibility of a shortfall being reported. It stops short of cost/rate-limit or timeout guidance.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three tightly packed sentences: purpose first, return value second, operational polling protocol third. No filler, and the workflow-critical instruction is not buried.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description carries the burden of explaining what comes back — a sourced slate, an optional synthesis, and a session_id — and it does so, plus the full polling protocol needed to actually retrieve the result. For an async, 8-parameter tool this is complete enough to invoke correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so baseline is 3, but the description adds value by tying example questions to the lens/synthesis choices and by warning that synthesis must be requested rather than assumed. The remaining parameters (window, count, source_quality) are left entirely to the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb+resource (ask an analyst-shaped question over a fresh niche scan) and immediately grounds it with three concrete example questions, so the agent knows the request shape it should construct. It also distinguishes itself from the fire-and-forget scanning siblings by declaring that it returns a session_id to be polled.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives clear when-to-use context (analyst-shaped questions, Pro tier) and prescribes the follow-up workflow precisely (poll niche_session_state until cp1_awaiting_story; then wait_until=synthesis with wait=30). It does not, however, contrast this against sibling tools such as niche_signal_scan or niche_feed_read, so the agent must infer which entry point fits a lighter query.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List your recent scans: id, the niche you described, status and timestamps. Use it to find a session_id you no longer have.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Max sessions to return (default 25, max 100). | |
| offset | No | Skip this many sessions before returning, for paging through history. Default 0. | |
| status_filter | No | Optional scan status, such as cp1_awaiting_story, cp2_awaiting_angle, complete, or failed. | |
| niche_contains | No | Optional case-insensitive substring filter on the niche input, to find sessions on a topic (e.g. 'walnut'). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=false, so safety is covered. The description usefully adds the shape of the returned list, but says nothing about ordering, pagination behavior beyond the schema, or result size limits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two tight sentences, with the returned-field summary front-loaded and the use case immediately after. No filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description correctly compensates by listing the returned fields. All four optional parameters are covered by the schema, so an agent has enough to call it; only ordering/pagination nuances are left implicit.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so limit, offset, status_filter and niche_contains are fully documented in the schema. The description adds no filtering or paging semantics beyond that, which meets the baseline for a well-documented schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb (List) and resource (your recent scans) and enumerates the returned fields: id, niche, status, timestamps. It is clearly distinguishable from mutation siblings like niche_session_cancel, though it does not explicitly name a sibling by contrast.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
'Use it to find a session_id you no longer have' gives a concrete trigger condition for calling the tool. It stops short of naming alternatives such as niche_session_state for inspecting one known session, so no exclusions are stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Cancel a scan that is still running.
| Name | Required | Description | Default |
|---|---|---|---|
| reason | No | Optional. Surfaced as session.error_message. | |
| session_id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare destructiveHint=true, readOnlyHint=false, and openWorldHint=false, so the safety profile is covered without description help. The description contributes the "still running" state constraint, but is silent on whether partial results are retained, whether cancellation is immediate vs graceful, and what happens to an already-finished session. With annotations carrying the destructive signal, this is adequate but thin.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single front-loaded sentence with zero filler and the key constraint (still running) stated up front. It is appropriately terse for a one-argument cancel operation, though it sits close to under-specification.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a destructive, non-readonly mutation with no output schema and only half the parameters documented, the description covers the essentials (what it cancels, which state it targets) but omits post-cancellation effects and partial-result behavior. Annotations cover the safety profile, so the remaining gap is moderate rather than severe.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 50%: reason is well documented in the schema ("Surfaced as session.error_message"), while session_id carries no description anywhere but is self-evident from the tool name. The description adds nothing beyond the schema, which is acceptable here since the non-obvious parameter is documented.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb (cancel) and resource (a running scan/session), so an agent can distinguish it from niche_session_state and niche_list_sessions at a glance. The only wrinkle is terminology drift between the tool name (session) and the description (scan), but the intent is unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
"Still running" implies a precondition (only active scans, not completed or queued ones), which is useful implied guidance. However, no alternative is named for cases when the session is not running, and no prerequisites or follow-up steps are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read the current state of a scan: status, the ranked stories with their sources and source information, and any angles already proposed. Poll this after niche_signal_scan or niche_intelligence_query until the slate is ready.
| Name | Required | Description | Default |
|---|---|---|---|
| view | No | status returns a short progress summary. full returns the stories and available angles. Default full. | full |
| wait | No | Wait up to 30 seconds for progress, then return the current state. Default 0. | |
| wait_for | No | Alias for wait_until. If both are supplied, wait_until takes precedence. | |
| session_id | Yes | session_id from niche_signal_scan. | |
| wait_until | No | With wait, return on change, an actionable checkpoint, or completion of synthesis. | change |
| since_status | No | Last status received. With wait and wait_until=change, return when it changes. | |
| include_unpicked | No | When true, return the full candidate set even after picks have been made. Default false (sparse: only the picked story / angle come back). Meaningful only with view='full'; ignored in view='status' (the lean envelope never carries the candidate slate). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the safety profile (readOnlyHint=true, destructiveHint=false, openWorldHint=false), so the bar is lower. The description adds genuine behavioral context: this is a polling tool whose state advances over time and whose loop ends when the slate is ready. It does not describe blocking/latency behavior, though the schema's wait parameters carry that.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with what is returned and followed by the polling instruction. No redundant restatement of the title or annotations; every clause earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
There is no output schema, so the description must characterize return values — and it does, listing status, ranked stories with sources, and proposed angles. The polling model is conveyed, though the distinction between view='status' and view='full' envelopes and the blocking semantics of wait are left entirely to the schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
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 seven parameters, including the view enum, wait, wait_until/wait_for, since_status, and include_unpicked. The description adds no parameter-level meaning beyond that, so the baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('Read the current state of a scan') and enumerates the payload returned: status, ranked stories with sources, and proposed angles. It also names the producing siblings (niche_signal_scan, niche_intelligence_query), which distinguishes it from niche_list_sessions and the read-only feed tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says when to call it — 'Poll this after niche_signal_scan or niche_intelligence_query until the slate is ready' — naming the upstream tools and the terminating condition. It stops short of stating when not to use it (e.g. versus niche_list_sessions for enumerating sessions), so it is clear context rather than full routing guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Scan a niche you describe, right now (Pro). Returns a ranked, sourced slate of the stories people in that field are talking about, with source links, the outlets, and why it matters. For a ready-made briefing use niche_feed_read instead. Assistant access requires Pro. Poll niche_session_state with the returned session_id until status is cp1_awaiting_story; the slate is in stories.
| Name | Required | Description | Default |
|---|---|---|---|
| niche | Yes | Niche / beat description (2-200 chars). Specific is better. | |
| recency | No | Reporting window: 24h, week, month, quarter, or year. Pair with recency_strict for a hard cutoff. | |
| recency_strict | No | Exclude reporting outside the requested window. Default false; strict windows can return fewer stories. | |
| source_quality | No | strict prioritizes well-supported stories; balanced is the default; broad includes less-established reporting. Inspect the returned sources before relying on a claim. | balanced |
| idempotency_key | No | Optional stable key for retries of the same scan, so a retry reuses the original run. | |
| thinking_budget | No | balanced returns a session_id immediately. fast waits briefly for stories and returns them if ready; otherwise poll niche_session_state. | balanced |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only cover safety/open-world flags, so the description adds real value: the Pro access requirement, the session-based async lifecycle, the terminal status to poll for, and the idempotency/retry semantics. It does not cover failure modes, timeouts, or cancellation (a niche_session_cancel sibling exists), which keeps it short of full disclosure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Four sentences, front-loaded with purpose, then alternative, prerequisite, and polling instructions – every sentence carries information. Minor redundancy from stating the Pro requirement twice ('right now (Pro)' and 'Assistant access requires Pro').
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema and 6 parameters, the description compensates well by describing the return contents, naming the `stories` field, and explaining the polling loop needed to retrieve results. It omits what to do on failure or how to cancel an in-flight session, which is a modest gap for an async job tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% and every parameter (niche, recency, recency_strict, source_quality, idempotency_key, thinking_budget) is already documented in the schema, including enum meanings. The description adds no syntax or format detail beyond that, so the baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description gives a concrete verb and resource ('Scan a niche you describe, right now') and states the output shape ('ranked, sourced slate of the stories... with source links, the outlets, and why it matters'). It explicitly distinguishes itself from the sibling niche_feed_read, so an agent can route without opening either schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Names the alternative and the condition that selects it ('For a ready-made briefing use niche_feed_read instead') and states the prerequisite ('Assistant access requires Pro'). It also spells out the async completion path: poll niche_session_state with the returned session_id until status is cp1_awaiting_story.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Orient in one read-only call: your plan (Free or Pro), the tools this server serves, and the endpoint. Assistant access requires Pro. Call it first if you are unsure what is available.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the safety profile (readOnly, non-destructive, closed-world), and the description adds real context beyond them: the specific contents of the response and the Pro gating constraint on assistant access. It stops short of stating rate limits or response format details, so not a full 5.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two tight sentences, front-loaded with the highest-value fact (what one read gets you) before the gating caveat and the call-first instruction. No filler or restatement of the name.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema and no parameters, the description carries the burden of saying what comes back, and it does list plan, served tools, and endpoint. Minor gaps remain about the shape of the tool list or how plan state is represented, but nothing essential is missing for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are zero parameters, so there is nothing for the description to disambiguate and the baseline is 4. The text correctly implies a no-argument call by describing it as a single orienting read.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('Orient in one read-only call') and enumerates exactly what it returns: plan tier, served tools, and endpoint. No sibling tool surfaces account or capability information, so the agent can distinguish it from the session/feed/query siblings without opening any schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
'Call it first if you are unsure what is available' gives a clear trigger condition, and 'Assistant access requires Pro' signals a prerequisite for downstream capabilities. It doesn't name alternative tools for narrower checks, but as a first-step discovery tool no alternative is obvious.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
niche_angle_propose4 fields changedInput schema / additionalPropertiesAdded value: +falseInput schema / properties / custom_framingRemoved value: -{
- "description": "Optional. Your own angle in a sentence ('the contrarian take: X is overhyped because Y'). When set, drafts that angle on the real story (provenance preserved) instead of returning the proposed five. Requires the story locked and angles ready (cp2_awaiting_angle).",
- "type": "string"
-}Input schema / properties / lens / descriptionPrevious value: -"Optional steer (e.g. 'more contrarian', 'lead with the data'). Read on a regenerate run, and as a fallback steer for a custom_framing draft when custom_framing is set without its own wording."New value: +"Optional direction for a regenerated angle set, such as focus on the evidence."Input schema / properties / regenerate / descriptionPrevious value: -"Generate a fresh set of angles on the locked story instead of returning the existing set. Requires the story locked and angles ready. Capped per session; metered like a generation."New value: +"Request another set of angles after the selected story's angles are ready. Subject to the account's allowance."niche_intelligence_query11 fields changedInput schema / additionalPropertiesAdded value: +falseInput schema / properties / brand_idRemoved value: -{
- "description": "Binds this brand's voice, colors, offer, and CTA to the piece. Omit to use your default brand; on a multi-brand account pass the slug explicitly so a post about one product is not bound to another brand's identity. niche_whoami lists your brands.",
- "type": "string"
-}Input schema / properties / count / descriptionPrevious value: -"How many developments / narratives to return (3-15). Default ~5-10."New value: +"Requested number of developments, from 3 to 15. The result can contain fewer when reporting is limited."Input schema / properties / idempotency_key / descriptionPrevious value: -"Optional. Stable key so a retry reuses the original run instead of billing a second; an identical query fired while one is still running is auto-deduped regardless."New value: +"Optional stable key for retries of the same scan, so a retry reuses the original run."Input schema / properties / lens / descriptionPrevious value: -"Ranking posture. 'mainstream' (default) = authority-weighted. 'emerging' = inverts saturation to surface low-coverage, pre-mainstream signal. 'investment' = lifts stories carrying funding/raise/round/term-sheet markers."New value: +"mainstream covers established reporting, emerging emphasizes newer topics, and investment focuses on funding developments."Input schema / properties / platformRemoved value: -{
- "description": "Optional publish target (linkedin / x / instagram) that shapes each narrative's publish_hook.",
- "type": "string"
-}Input schema / properties / recency_strict / descriptionPrevious value: -"When true, `window` is a hard cutoff (out-of-window sources dropped before clustering) so 'nothing older than yesterday' is exact. Default false (bias only). Strict returns fewer, higher-confidence stories; use when precision matters more than breadth."New value: +"Exclude reporting outside the requested window. Default false; strict windows can return fewer stories."Input schema / properties / source_quality / descriptionPrevious value: -"Source-quality filter (niche-relative). 'strict' drops uncorroborated single-source silos that aren't primary/official or a niche authority, for high-trust answers only. 'balanced' (default) down-weights weak sources without dropping. 'broad' surfaces everything (incl. low-coverage emerging clusters), authority as a tiebreaker only."New value: +"strict prioritizes well-supported stories; balanced is the default; broad includes less-established reporting. Inspect the returned sources before relying on a claim."Input schema / properties / synthesis / descriptionPrevious value: -"'narratives' = N non-obvious publishable threads across the slate. 'patterns' = the named movement (pairs with lens:'investment'). 'none' (default) = ranked slate only, no synthesis."New value: +"none returns stories only. narratives adds sourced themes across the stories. patterns adds a summary of broader developments. Default none."Input schema / properties / target_outputsRemoved value: -{
- "description": "Optional. The draft cells produced if you later draft a narrative into content (same cell list as niche_signal_scan, e.g. ['linkedin:image_post', 'x:thread']). Without this, a draft defaults to a single 'long_form_article'. Set it when you know the surfaces you want, so niche_draft_create yields them directly instead of needing niche_add_output after.",
- "items": {
- "type": "string"
- },
- "type": "array"
-}Input schema / properties / window / descriptionPrevious value: -"Recency window: '24h' | 'week' | 'month' | 'quarter' | 'year'. 'this week' maps to 'week'. Overrides the niche's default recency. A strong bias by default; pair with recency_strict for a hard cutoff."New value: +"Reporting window: 24h, week, month, quarter, or year. Pair with recency_strict for a hard cutoff."niche_list_sessions4 fields changedInput schema / additionalPropertiesAdded value: +falseInput schema / properties / brand_idRemoved value: -{
- "description": "Optional filter to sessions tied to one brand profile slot.",
- "type": "string"
-}Input schema / properties / include_outputsRemoved value: -{
- "default": false,
- "description": "When true, also returns `recent_outputs`: the account's produced posts/images/reels across all sessions, newest first, each with its session_id, cell, a reachable asset_url, and publish state. Use it to locate a past asset (e.g. an image made on a prior run). Default false.",
- "type": "boolean"
-}Input schema / properties / status_filter / descriptionPrevious value: -"Optional status filter, e.g. 'cp1_awaiting_story', 'cp3_awaiting_review', 'complete', 'failed'. Omit for all."New value: +"Optional scan status, such as cp1_awaiting_story, cp2_awaiting_angle, complete, or failed."niche_session_cancel1 field changedInput schema / additionalPropertiesAdded value: +falseniche_session_state9 fields changedInput schema / additionalPropertiesAdded value: +falseInput schema / properties / include_status_glossaryRemoved value: -{
- "default": false,
- "description": "When true, response includes `status_glossary[]`, the full 17-status state-machine descriptor list with phase, hint, and `actionable` (whether a wait_until='checkpoint' wakes for it) per status. Useful on the first call of an agent session so the agent caches the full map; leave false on subsequent polls. Default false.",
- "type": "boolean"
-}Input schema / properties / since_status / descriptionPrevious value: -"Used with `wait` (wait_until='change'). The status the caller last saw; the wait returns as soon as session.status differs. If unset, any state-change event wakes the wait. Note the pipeline has paired vocabulary: a transient `cpN_generating` (checkpoint about to produce) and a `generating_*` work status (e.g. cp2_generating maps to generating_angles). To skip both and wake only at the next actionable stop, use wait_until='checkpoint' rather than chasing since_status through the intermediates."New value: +"Last status received. With wait and wait_until=change, return when it changes."Input schema / properties / view / descriptionPrevious value: -"`status` (lean): a few-hundred-byte control envelope of status, phase, picked ids, `content_versions` (per-section change counters), `counts`, `output_ids`, cost, and next_step. Use this for the poll loop. `full` (default): the complete state with stories/angles/outputs. Fetch `full` once when a content_version moves, rather than re-shipping the full state every poll. Pairs with wait plus since_status."New value: +"status returns a short progress summary. full returns the stories and available angles. Default full."Input schema / properties / wait / descriptionPrevious value: -"Long-poll for up to N seconds (0-30) waiting for the session state to change. Returns immediately if the state already differs from `since_status` (or if the session is awaiting a checkpoint / complete / failed). Drops agent token burn from N polls to 1 wait. Default 0 (no wait, behave as before)."New value: +"Wait up to 30 seconds for progress, then return the current state. Default 0."Input schema / properties / wait_for / descriptionPrevious value: -"Alias for `wait_until` (same values and semantics). Use either; if both are set, `wait_until` wins. An unrecognized value is rejected (not silently ignored), and it only takes effect with `wait` > 0."New value: +"Alias for wait_until. If both are supplied, wait_until takes precedence."Input schema / properties / wait_for / enumPrevious value: -[
- "change",
- "checkpoint",
- "render",
- "synthesis"
-]New value: +[
+ "change",
+ "checkpoint",
+ "synthesis"
+]Input schema / properties / wait_until / descriptionPrevious value: -"What the `wait` long-poll resolves on. `change` (default): any status change vs since_status, a reached checkpoint, or a status-less change (synthesis fill, render completion, new output). `checkpoint`: only an actionable checkpoint (cpN_awaiting_* / complete / failed), skipping the noisy intermediate cpN_generating and generating_* transitions, so you get one wake per checkpoint. `render`: a reel/image render marker settles (done|failed). Use this after niche_render_reel / niche_render_image_card, since a render leaves status unchanged and won't wake a `change` wait on status alone. Works on a session already at complete (the normal case, since renders are post-completion add-ons): the wait holds on the render marker, not the session status. `synthesis`: a niche_intelligence_query's synthesis lands (narratives or a shortfall_note). Synthesis filling is not a status change, so block on this in one call instead of busy-polling."New value: +"With wait, return on change, an actionable checkpoint, or completion of synthesis."Input schema / properties / wait_until / enumPrevious value: -[
- "change",
- "checkpoint",
- "render",
- "synthesis"
-]New value: +[
+ "change",
+ "checkpoint",
+ "synthesis"
+]niche_signal_scan12 fields changedInput schema / additionalPropertiesAdded value: +falseInput schema / properties / brand_idRemoved value: -{
- "description": "Binds this brand's voice, colors, offer, and CTA to the piece. Omit to use your default brand; on a multi-brand account pass the slug explicitly so a post about one product is not bound to another brand's identity. niche_whoami lists your brands.",
- "type": "string"
-}Input schema / properties / densityRemoved value: -{
- "default": "balanced",
- "description": "How tightly to pack visual formats (carousels especially).\n • minimal: split a dense argument across more, shorter slides; favors skimmability.\n • balanced (default): the standard per-slide caps.\n • essay: permissive; allows longer slides/sections.\nOver-cap slides auto-split on sentence boundaries (never mid-sentence); over-280 tweets split into a chain regardless.",
- "enum": [
- "minimal",
- "balanced",
- "essay"
- ],
- "type": "string"
-}Input schema / properties / estimate_onlyRemoved value: -{
- "default": false,
- "description": "When true, return the discovery credit cost without starting a run or holding a reservation. Use it to quote a price before committing.",
- "type": "boolean"
-}Input schema / properties / idempotency_key / descriptionPrevious value: -"Optional. A stable key for this logical scan: a retry with the same key reuses the original run instead of starting (and billing) a second. Even without it, an identical scan fired while one is still running is auto-deduped."New value: +"Optional stable key for retries of the same scan, so a retry reuses the original run."Input schema / properties / profile_overridesRemoved value: -{
- "description": "Optional. Deep-merge these overrides onto the persisted profile for this run only. Use case: same brand, different register for a specific piece (e.g. a product-launch voice over an editorial one). Requires brand_id.",
- "type": "object"
-}Input schema / properties / recency / descriptionPrevious value: -"Optional recency window that constrains discovery to fresh sources. One of '24h' | 'week' | 'month' | 'quarter' | 'year' (aliases: 'today'/'day'→24h, 'this week'→week, etc.). Use '24h' for 'today only / breaking'. Putting the demand in the niche string does not constrain recency; use this param. Omit to use the niche's default window."New value: +"Reporting window: 24h, week, month, quarter, or year. Pair with recency_strict for a hard cutoff."Input schema / properties / recency_strict / descriptionPrevious value: -"When true, `recency` is a hard cutoff: sources outside the window are dropped before clustering, so 'nothing older than yesterday' is honored exactly. Default false: the window is a strong bias but older corroborating sources can still attach to a fresh cluster. Set true when exactness matters more than slate depth (strict can thin the slate)."New value: +"Exclude reporting outside the requested window. Default false; strict windows can return fewer stories."Input schema / properties / source_quality / descriptionPrevious value: -"How aggressively to filter the slate on source quality (niche-relative; never penalizes a small publication that is the authority for the niche).\n • strict: drop uncorroborated single-source silos that aren't a primary/official or a niche authority; surfaces only well-sourced stories. Can thin the slate.\n • balanced (default): down-weight weak sources, don't drop.\n • broad: surface everything, including low-coverage emerging clusters, with authority as a tiebreaker only.\nUse strict for a high-trust brief, broad to scout early signal."New value: +"strict prioritizes well-supported stories; balanced is the default; broad includes less-established reporting. Inspect the returned sources before relying on a claim."Input schema / properties / target_outputsRemoved value: -{
- "description": "Output cells to generate (platform×content_type matrix). Each cell is a 'platform:content_type' string or a cross-platform content type. Valid cells:\n • linkedin:text_post: short LinkedIn post (text only)\n • linkedin:image_post: LinkedIn post plus 1.91:1 image card\n • linkedin:carousel: multi-slide carousel\n • linkedin:reel: LinkedIn-native vertical video\n • x:single_tweet: standalone tweet\n • x:thread: multi-tweet thread\n • x:image_post: tweet plus 16:9 image card\n • x:reel: tweet plus 9:16 video\n • instagram:image_post: caption plus 4:5 image card\n • instagram:carousel: multi-image swipe\n • instagram:reel: caption plus 9:16 reel\n • long_form_article: universal essay (Substack/blog)\n\nA bare platform name also works and maps to that platform's default cell: 'x'/'twitter'→x:single_tweet (pass 'x:thread' for a thread), 'linkedin'/'li'→linkedin:text_post, 'instagram'/'ig'→instagram:image_post, 'longform'→long_form_article. The resolved cells are echoed back as target_outputs.\nDefaults to ['linkedin:text_post']; request only the cells you need (each additional cell adds generation cost).",
- "items": {
- "type": "string"
- },
- "type": "array"
-}Input schema / properties / target_platformsRemoved value: -{
- "description": "Optional. A flat platform list (linkedin, linkedin_carousel, twitter, longform, instagram), coerced into target_outputs cells. Prefer target_outputs.",
- "items": {
- "type": "string"
- },
- "type": "array"
-}Input schema / properties / thinking_budget / descriptionPrevious value: -"Agent-side polling control. A full editorial workflow is structurally 15-20 tool calls (scan, poll, poll, poll, pick, poll, pick, poll, read). Use this to tune how many of those calls collapse into single waits.\n • fast: scan blocks briefly (up to ~45s, under the tool-call timeout) for CP1 and returns the stories inline when they land in time. One call instead of many polls. Cheaper agent tokens, smaller cognitive surface. If CP1 isn't ready by the cap it still returns the session_id (status=discovering); poll niche_session_state from there, the run is never lost. Pick when you just want stories and the user is waiting.\n • balanced (default): scan returns immediately with session_id; the agent polls niche_session_state (with wait plus since_status long-poll)."New value: +"balanced returns a session_id immediately. fast waits briefly for stories and returns them if ready; otherwise poll niche_session_state."niche_whoami3 fields changedInput schema / properties / include_all_brandsRemoved value: -{
- "default": false,
- "description": "List every brand on the account in available_brands. Default false: only the active brand is returned (with other_brand_count) so a single orienting call does not enumerate the whole roster. Set true when you genuinely need to pick among multiple brands.",
- "type": "boolean"
-}Input schema / properties / include_brand_assetsRemoved value: -{
- "default": false,
- "description": "Include usable brand asset URLs (logo, wordmark) in brand_palette. Default false: the palette returns colours and fonts plus logo_available / wordmark_available booleans, and the renderer fetches the actual asset when a render needs it. Set true only if you need the asset URL directly.",
- "type": "boolean"
-}Input schema / properties / include_testRemoved value: -{
- "default": false,
- "description": "Include scratch and experimental brand slots in available_brands. Default false so only real brands are listed and an agent does not bind a throwaway by accident.",
- "type": "boolean"
-}niche_add_outputniche_attach_imageniche_brand_kit_guided_setupniche_brand_kit_ingestniche_brand_kit_ingest_statusniche_brand_kit_updateniche_brand_profile_getniche_brand_profile_setniche_draft_createniche_draft_directniche_draft_publishniche_draft_reviseniche_render_image_cardniche_render_reelniche_reuse_assetniche_session_exportniche_session_revertniche_voice_profile_ingestniche_feed_readniche_signal_scan1 field changedInput schema / properties / target_outputs / descriptionPrevious value: -"Output cells to generate (platform×content_type matrix). Each cell is a 'platform:content_type' string or a cross-platform content type. Valid cells:\n • linkedin:text_post: short LinkedIn post (text only)\n • linkedin:image_post: LinkedIn post plus 1.91:1 image card\n • linkedin:carousel: multi-slide carousel\n • linkedin:reel: LinkedIn-native vertical video\n • x:single_tweet: standalone tweet\n • x:thread: multi-tweet thread\n • x:image_post: tweet plus 16:9 image card\n • x:reel: tweet plus 9:16 video\n • instagram:image_post: caption plus 4:5 image card\n • instagram:carousel: multi-image swipe\n • instagram:reel: caption plus 9:16 reel\n • long_form_article: universal essay (Substack/blog)\n\nA bare platform name also works and maps to that platform's default cell: 'x'/'twitter'→x:thread, 'linkedin'/'li'→linkedin:text_post, 'instagram'/'ig'→instagram:image_post, 'longform'→long_form_article. The resolved cells are echoed back as target_outputs.\nDefaults to ['linkedin:text_post']; request only the cells you need (each additional cell adds generation cost)."New value: +"Output cells to generate (platform×content_type matrix). Each cell is a 'platform:content_type' string or a cross-platform content type. Valid cells:\n • linkedin:text_post: short LinkedIn post (text only)\n • linkedin:image_post: LinkedIn post plus 1.91:1 image card\n • linkedin:carousel: multi-slide carousel\n • linkedin:reel: LinkedIn-native vertical video\n • x:single_tweet: standalone tweet\n • x:thread: multi-tweet thread\n • x:image_post: tweet plus 16:9 image card\n • x:reel: tweet plus 9:16 video\n • instagram:image_post: caption plus 4:5 image card\n • instagram:carousel: multi-image swipe\n • instagram:reel: caption plus 9:16 reel\n • long_form_article: universal essay (Substack/blog)\n\nA bare platform name also works and maps to that platform's default cell: 'x'/'twitter'→x:single_tweet (pass 'x:thread' for a thread), 'linkedin'/'li'→linkedin:text_post, 'instagram'/'ig'→instagram:image_post, 'longform'→long_form_article. The resolved cells are echoed back as target_outputs.\nDefaults to ['linkedin:text_post']; request only the cells you need (each additional cell adds generation cost)."niche_angle_propose1 field changedInput schema / properties / lens / descriptionPrevious value: -"Optional steer for a regenerate run (e.g. 'more contrarian', 'lead with the data'). Only read when regenerate is true."New value: +"Optional steer (e.g. 'more contrarian', 'lead with the data'). Read on a regenerate run, and as a fallback steer for a custom_framing draft when custom_framing is set without its own wording."niche_brand_kit_update1 field changedInput schema / properties / nameAdded value: +{
+ "description": "Rename an existing brand's display name (its brand_id is unchanged).",
+ "type": "string"
+}niche_render_image_card2 fields changedInput schema / properties / background_color / descriptionPrevious value: -"The background colour of a SOLID brand card (background='brand_color') as a name ('cream'/'navy'), a hex, or a brand keyword ('primary'/'accent'/'secondary'). Applies on scope='recomposite' for no charge and persists, so the colour does not snap back to the brand default on a later edit. (A generated-photo card recolours its text, not its photo background.)"New value: +"The background colour of a SOLID brand card (background='brand_color') as a name ('cream'/'navy'), a hex, or a brand keyword ('primary'/'accent'/'secondary'). Applies on a full brand_color render AND on scope='recomposite' (free, persists, so the colour does not snap back to the brand default on a later edit). (A generated-photo card recolours its text, not its photo background.)"Input schema / properties / design_color / descriptionPrevious value: -"Optional, background='design' only: manual color control. Free text ('blue', 'navy accent', '#0a3d62'). Overrides the accent for the design card; the rest stays on the brand's palette (or the default style when the brand has no kit set). Omit to use the brand's own accent."New value: +"Optional, background='design': color control for the design card. Free text. Sets the card BACKGROUND when the phrase names a background or the card overall ('cream background', 'navy', 'on a green card'), or the ACCENT when it names one ('blue accent', '#0a3d62'); the rest stays on the brand's palette (or the default style when the brand has no kit). Omit to use the brand's palette."niche_whoami1 field changedInput schema / properties / include_brand_assetsAdded value: +{
+ "default": false,
+ "description": "Include usable brand asset URLs (logo, wordmark) in brand_palette. Default false: the palette returns colours and fonts plus logo_available / wordmark_available booleans, and the renderer fetches the actual asset when a render needs it. Set true only if you need the asset URL directly.",
+ "type": "boolean"
+}niche_whoami1 field changedInput schema / properties / include_all_brandsAdded value: +{
+ "default": false,
+ "description": "List every brand on the account in available_brands. Default false: only the active brand is returned (with other_brand_count) so a single orienting call does not enumerate the whole roster. Set true when you genuinely need to pick among multiple brands.",
+ "type": "boolean"
+}niche_draft_create1 field changedInput schema / properties / brand_idAdded value: +{
+ "description": "Bind this draft to a brand (its voice/offer/CTA). Usually unnecessary (the run inherits the scan's brand). Pass it to answer a `brand_choice_required` on a multi-brand account, or `'none'` to draft deliberately unbranded.",
+ "type": "string"
+}niche_draft_publish1 field changedInput schema / properties / acknowledge_publish_costAdded value: +{
+ "default": false,
+ "description": "Required true to commit an X post that carries a link (X charges per link-post, so the dry-run returns a `publish_cost` in credits). Affirms the agent showed the human the cost and got go-ahead. Ignored when the publish is free (plain X / LinkedIn / Instagram). Default false.",
+ "type": "boolean"
+}niche_render_image_card3 fields changedInput schema / properties / background / descriptionPrevious value: -"Required for scope='full' (ignored otherwise): what's behind the text. 'photo' = a generated AI/photographic image (the actual picture; ~30 credits, ~30-90s, async). 'design' = a generated editorial design graphic that draws the argument (concept diagram / stat / pull-quote / comparison / method / abstract), on-brand and legible, no photo, no clichés, ~30 credits, async. 'brand_color' = a free, instant flat brand card (no generation). No default: choose deliberately."New value: +"Required for scope='full' (ignored otherwise): what's behind the text. 'photo' = a generated AI/photographic image (the actual picture; ~30 credits, ~30-90s, async). 'design' = a generated editorial design graphic that draws the argument (concept diagram / stat / pull-quote / comparison / method / abstract), on-brand and legible, no photo, no clichés, ~30 credits, async. 'brand_color' = a free, instant flat brand card (no generation). 'svg' = a free, instant card you author exactly as SVG markup (pass `svg`), rasterized at the cell's size; best for data, labels, and charts, and the only visual that works from a network-locked sandbox. No default: choose deliberately."Input schema / properties / background / enumPrevious value: -[
- "photo",
- "brand_color",
- "design"
-]New value: +[
+ "photo",
+ "brand_color",
+ "design",
+ "svg"
+]Input schema / properties / svgAdded value: +{
+ "description": "Required when background='svg': the card's SVG markup as a string (<svg ...>...</svg>). You author the exact layout; the server rasterizes it to the cell's pixel dimensions. Use brand colors and fonts from niche_whoami to stay on-brand. Bundled fonts (set font-family to any by name; an unknown family or the generics 'sans-serif'/'serif'/'monospace' fall back to a real font so text always draws): sans (Inter, Geist, Open Sans, Montserrat, Lato, Poppins, DejaVu Sans), serif (DejaVu Serif, Lora, Playfair Display), mono (DejaVu Sans Mono, JetBrains Mono). Allowed: static shapes, paths, text, gradients, internal (#id) and inline data: references. Rejected with a named error: scripts, event handlers, foreignObject, external/file references, and DOCTYPE/ENTITY declarations. Max 512KB.",
+ "type": "string"
+}niche_attach_image2 fields changedInput schema / properties / image / descriptionPrevious value: -"Inline image as base64: {mime_type, data_base64} (plus optional name). Max 8MB, but large inline payloads are unreliable over MCP, so prefer image_url or image_chunk. One of image_url / image / image_chunk is required."New value: +"Inline image as base64: {mime_type, data_base64} (plus optional name). Max 8MB, but large inline payloads are unreliable over MCP, so prefer upload_ref or image_url. One of upload_ref / image_url / image / image_chunk is required."Input schema / properties / image_url / descriptionPrevious value: -"A fetchable image URL (https). Preferred for full-resolution assets: the server fetches and stores it, so you don't inline a large base64 payload. One of image_url or image is required."New value: +"A fetchable image URL (https). For an asset that already lives on the web: the server fetches and stores it, so you don't inline a large base64 payload. One of upload_ref / image_url / image / image_chunk is required."niche_attach_image3 fields changedInput schema / properties / image_chunk / descriptionPrevious value: -"Chunked upload for bring-your-own bytes you hold locally (no URL). Split the file's BYTES into ~32-48KB pieces, base64-encode EACH piece, send in order. Omit upload_id on the first chunk (the response returns one); set final:true on the last. The final call assembles + attaches. Use this for agent-built graphics; it's reliable where a single large inline payload is not."New value: +"Chunked upload for bring-your-own bytes you hold locally (no URL). Split the file's BYTES into ~32-48KB pieces, base64-encode EACH piece, send in order. Always include a per-chunk `sha256` (hex of that piece's raw bytes): the server verifies it and rejects a mis-transcribed chunk so you resend just that one, which is what makes this path reliable (valid base64 can still decode to wrong bytes and silently corrupt the image). Omit upload_id on the first chunk (the response returns one); set final:true on the last, optionally with `total_sha256` of the whole file."Input schema / properties / image_chunk / properties / sha256Added value: +{
+ "description": "hex sha256 of THIS chunk's raw bytes (before base64). Strongly recommended: the server verifies it and tells you to resend the chunk if it was mis-transcribed.",
+ "type": "string"
+}Input schema / properties / image_chunk / properties / total_sha256Added value: +{
+ "description": "On the final chunk only: hex sha256 of the WHOLE assembled file, for an end-to-end integrity check.",
+ "type": "string"
+}niche_attach_image1 field changedInput schema / properties / upload_refAdded value: +{
+ "description": "FAST bring-your-own path. First POST the raw file to /asset/upload (multipart/form-data field 'file', Authorization: Bearer <token>); the response returns an upload_ref. Pass it here. The bytes go over HTTP, not through the model, so it's instant for a real graphic. Preferred whenever the agent can run a shell.",
+ "type": "string"
+}niche_add_outputniche_angle_proposeniche_attach_imageniche_brand_kit_guided_setupniche_brand_kit_ingestniche_brand_kit_ingest_statusniche_brand_kit_updateniche_brand_profile_getniche_brand_profile_setniche_draft_createniche_draft_directniche_draft_publishniche_draft_reviseniche_intelligence_queryniche_list_sessionsniche_render_image_cardniche_render_reelniche_reuse_assetniche_session_cancelniche_session_exportniche_session_revertniche_session_stateniche_signal_scanniche_voice_profile_ingestniche_whoamiFree AI-curated news summaries from 100+ sources across seven beats, plus entity dossiers.
Monitor news sources, read clustered articles and generated texts, manage goals and workflows.
Agents that watch the sources you approve and write cited Briefs, from your AI tools.
Google Trends, Google News, Hacker News, Substack posts and podcasts for research and monitoring.
Add one secure layer between your agents and this server.