niche_whoamiOrient 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 arguments | |||
Changes observed during successful MCP inspections.
Input 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"
-}Input 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"
+}Input 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"
+}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.
Add one secure layer between your agents and this server.