PostNitro

Create Brand

postnitro_create_brand

Create a new brand kit (the logo, name, and handle stamped onto generated carousels).

All seven fields are required. The new brand's ID is returned — use it as a brandId in generate/import or save it via postnitro_set_defaults.

Note: plans cap the number of brands; exceeding it returns an error.

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>",
      "handle": "<handle>",
      "image": "<image>",
      "isCompanyDetail": "<isCompanyDetail>",
      "showName": "<showName>",
      "showHandle": "<showHandle>",
      "showImage": "<showImage>"
    },
    "name": "postnitro_create_brand"
  }
}

Input Schema

Name	Required	Description
`name`	Yes	Brand display name (required)
`image`	Yes	Logo image URL (required)
`handle`	Yes	Social handle, e.g. '@postnitroai' (required)
`showName`	Yes	Render the name on slides
`showImage`	Yes	Render the logo on slides
`showHandle`	Yes	Render the handle on slides
`idempotencyKey`	No	Optional key that makes this call safe to retry. Generate a new one (e.g. a UUID) for each new action. If the call times out, fails with a network or 5xx error, or you are unsure it went through, call again with the SAME key and the same arguments: PostNitro returns the first call's result instead of creating a second post, charging credits again or scheduling a duplicate. Only a successful call is remembered, so after an error you can fix the arguments and retry with the same key; reusing a successful call's key with different arguments is rejected (422).
`isCompanyDetail`	Yes	Treat as a company brand (vs personal)

Output Schema

Name	Required	Description
`brand`	Yes	The brand that was created
`message`	Yes	Confirmation message
`success`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedNov 1, 2026

addedInput schema / properties / idempotencyKey

Added value: +{
+  "description": "Optional key that makes this call safe to retry. Generate a new one (e.g. a UUID) for each new action. If the call times out, fails with a network or 5xx error, or you are unsure it went through, call again with the SAME key and the same arguments: PostNitro returns the first call's result instead of creating a second post, charging credits again or scheduling a duplicate. Only a successful call is remembered, so after an error you can fix the arguments and retry with the same key; reusing a successful call's key with different arguments is rejected (422).",
+  "pattern": "^[\\x21-\\x7E]{1,200}$",
+  "type": "string"
+}

First observedSep 7, 2026

TDQS

A4.2/5.0

Behavior4/5

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

Beyond the annotations (readOnly=false, destructive=false, idempotent=false), the description adds two real behavioral facts: the plan-level cap on brand count and that exceeding it returns an error. It also confirms the new brand's ID is returned. It does not mention the idempotencyKey retry-safety mechanism, though the annotations' idempotentHint=false is not contradicted since the safety comes only from the explicit key.

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?

Three short paragraphs: purpose first, then the required-fields/returned-ID mechanic, then the error caveat. Every sentence carries information an agent would otherwise have to infer, and nothing is repeated from the schema verbatim.

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?

With an output schema present, return values need not be spelled out, yet the description still notes the returned ID and its intended use. It covers required-field enforcement and a failure mode (plan cap). The only gap is any mention that retries should reuse idempotencyKey, which is left entirely to the schema for a non-idempotent create.

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 including the richly documented idempotencyKey already carries its own semantics. The description only adds the aggregate constraint 'all seven fields are required' and the framing that the fields are stamped onto carousels, which is a marginal gain over the schema. Baseline 3 applies when the schema does the heavy lifting.

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 lead sentence gives a specific verb+resource ('Create a new brand kit') and immediately defines what a brand kit is ('the logo, name, and handle stamped onto generated carousels'), which the bare name 'Create Brand' does not convey. Against siblings like postnitro_update_brand, postnitro_get_brand and postnitro_list_brands the create semantics are 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 tells the agent what to do with the result — 'use it as a brandId in generate/import or save it via postnitro_set_defaults' — which gives clear downstream context with no exclusions. It does not explicitly say 'if a brand already exists, use postnitro_update_brand instead', so the create-vs-update decision is left implicit.

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

All PostNitro 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?