flayr

Set or add internal post and instance labels

edit_post_labels

Idempotent

[writes flayr data · write scope] Sets internal post labels and per-platform/account instanceLabels. Omitted sets stay unchanged; [] clears a set; labelMode set replaces both sets, add appends atomically. Use get_post to list both. Works after booking and publishing, and never contacts social networks. Labels are key:value (campaign, experiment, variant, repost, series, source-run, or free keys). Needs publish scope and the publishing plan. (Wraps PATCH /api/v2/posts/{id}.)

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": {
      "id": "<id>"
    },
    "name": "edit_post_labels"
  }
}

Input Schema

Name	Required	Description
`id`	Yes	The post: `convexPostId` from POST /api/v2/publish, or `posts[].id` from GET /api/v2/content/{id}.
`labels`	No	Sets this post's own labels ([] or null clears; labelMode add appends), e.g. ["repost:evergreen"]. flayr metadata: sent alone it never touches the booking (status "labeled") and works on posted posts too. With booking edits, metadata is saved after a successful edit. Normalized "key:value" labels (keys and values are lower-cased, spaces become "-"). Linked keys: campaign:<media campaign id>, experiment:<experiment id> (+ variant:<name> or the experiment's compareKey), type:<post type> (short, long-form, carousel, image, text, reel, story, poem, timelapse…). Free keys work too: cut:opus, lane:tech, parent:pantheon-part-1, ab:<pair id> (an A/B pair). Labels are copied onto every post made from the draft, and compared in GET /api/v2/analytics/experiments.
`labelMode`	No	Default set. add atomically appends labels to the post and matching instances; other instances stay unchanged.
`instanceLabels`	No	Internal labels per platform/account instance. An array of {platform, accountId?, labels}; accountId is the Zernio connected account id. Omit accountId when unknown. instanceKey is derived as canonical platform + ":account:" + URL-encoded account id, or ":pending" when unknown (twitter canonicalizes to x). Replaces the instance set when editing; [] clears it. Never published.

Schema Changelog

Changes observed during successful MCP inspections.

AddedNov 7, 2026

TDQS

A4.5/5.0

Behavior5/5

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

Beyond the annotations, it discloses the write scope and publish-scope requirement, that omitted sets stay unchanged, that [] clears, that labelMode 'set' replaces both sets while 'add' appends atomically, and that metadata-only edits save after a successful booking edit. These are exactly the mutation semantics an agent cannot infer from readOnlyHint/destructiveHint/idempotentHint alone.

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?

Front-loaded with scope tag and verb, then the state semantics, then prerequisites, then the HTTP endpoint as a trailing aside. Dense but nearly every clause carries information; the parenthetical PATCH note and some jargon ('flayr data') are the only soft spots.

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?

For a mutating tool with no output schema, it covers scopes, clearing/append behavior, and side effects, and points at get_post for reading labels back. It stops short of describing what a successful response contains (e.g. the resulting label set or status 'labeled' details beyond one clause).

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 coverage is already 100%, so the baseline is 3, but the prose adds real interaction meaning: the precedence between labelMode and the label sets, the key:value normalization, linked versus free keys, and how instanceKey is derived. That is more than restating field descriptions, though much of it duplicates the schema text.

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?

States a specific verb and resource: it sets internal post labels plus per-platform/account instanceLabels, and explicitly says it 'never contacts social networks'. That contrasts cleanly with siblings like get_post (read), labels_bulk_edit (bulk), and compare_labels (analysis).

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?

Gives concrete when-to-use context: it works after booking and publishing, and 'Use get_post to list both' names where to read current labels. It does not mention labels_bulk_edit versus per-post editing, or when to prefer bulk over this tool, so the routing guidance is strong but not exhaustive.

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

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