Skip to main content
Glama
hermoso-ai

Hermoso

Official

Add or remove a Partnership Ads creator

manage_meta_partnership_creator
Idempotent

Add or remove a creator from Meta Partnership Ads lists (run-as-advert or tag-approval). Confirms actual status via read-back, not the write reply.

Instructions

Add a creator to — or remove one from — this brand’s Partnership Ads lists. Name at least one list: allowAds (whose content this brand may RUN AS AN ADVERT) and/or allowTagging (who may TAG this brand as a paid partner on their own post). NEITHER DEFAULTS ON, because one of them lets somebody attach this brand’s name to their own post. ADDING IS A REQUEST, NOT AN APPROVAL: Meta’s own name for the operation is "send permission request", the creator accepts on their own Instagram account in their own time, and until the read-back reports approved this brand cannot advertise their content. Never tell anyone a partnership is live off the back of this call — report the status the reply carries. THE OUTCOME IS READ BACK OFF META’S OWN LIST, NEVER TAKEN FROM THE WRITE’S REPLY — because Meta answers the ADD with HTTP 500 (code 1, “Please reduce the amount of data you’re asking for”) while performing it, measured 4/4 on 2026-08-25. If this reply carries metaWriteError alongside a successful summary, that error is Meta noise about a write that HAPPENED: do not retry, and do not tell the user it failed. The reply’s verdict is one of applied / already / unchanged / unknown, and unknown means the list could not be re-read — which is not the same as nothing having changed. REMOVING FLIPS A STATUS TO “Canceled”; it does not delete the row. One tool does both lists because Meta removes from them with two DIFFERENT verbs (DELETE on one, a revoke flag on the other) and a caller who assumes one silently does nothing on the other. 0 credits.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
pageIdNoFacebook Page id — omit when only one Page is connected
removeNorevoke instead of add
creatorYesthe creator’s Instagram @username, or their numeric Instagram account id. The ad-permission list accepts either; the tag-approval list takes numeric ids ONLY, because Meta publishes no username form for its parameter — use instagram_profile to turn the handle into that id. An id that did not come from Meta is rejected with “An unknown error has occurred.” (HTTP 500, code 1), which names no cause and looks like an outage rather than a bad argument.
allowAdsNothe Partnership Ads permission list — whose content this brand may run as an advert
creatorIdsNofor `allowTagging`, which accepts several NUMERIC ids at once. A handle here is refused by name rather than sent and rejected by Meta — run instagram_profile on each handle first and pass the ids it returns.
allowTaggingNothe tag-approval list — who may tag this brand as a paid partner on their own organic post
Behavior5/5

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

Exceptional disclosure beyond the annotations: adding is a request-not-approval with a delayed acceptance window; Meta answers the ADD with HTTP 500 (code 1) while actually performing it (measured 4/4); metaWriteError alongside success means the write happened and must not be retried; the verdict 'unknown' means the list couldn't be re-read, not that nothing changed; removal flips status to 'Canceled' rather than deleting. This aligns with idempotentHint=true (don't retry) and destructiveHint=false (no delete), adding deep context the annotations cannot express.

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 long, but nearly every sentence carries a distinct and consequential fact (the HTTP 500 quirk, request-vs-approval, verdict semantics, the dual-verb justification). The core purpose is front-loaded. It is denser than strictly necessary — the dual-verb rationale and the measured-quirk note could be trimmed — but given the tool's genuine complexity, the length earns most of its keep.

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?

With no output schema, the description fully carries the burden of explaining the reply semantics (verdict values applied/already/unchanged/unknown, metaWriteError handling). It covers both lists, both directions, failure modes, retry guidance, and the id-type restrictions. Nothing an agent needs to call it correctly and interpret the result is missing.

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 coverage is 100% and the input schema's own parameter descriptions are already rich (creator accepts either form, tag-approval takes numeric ids only, rejection behavior). The tool description mostly reinforces the allowAds/allowTagging semantic distinction already present in the schema. It adds useful narrative framing but does not materially extend what the schema documents, so the baseline 3 is appropriate.

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 precise verb+resource statement: "Add a creator to — or remove one from — this brand's Partnership Ads lists," immediately naming the two lists (allowAds, allowTagging). It clearly differentiates from siblings like list_meta_partnership_creators (the read counterpart) and instagram_profile (the id-resolution tool referenced as a prerequisite). No ambiguity about what the tool does.

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?

Provides strong contextual guidance: when both lists default off, when to use instagram_profile to convert handles to ids (for allowTagging), when to use creatorIds, and how to interpret the reply. It does not explicitly name list_meta_partnership_creators as the read-back alternative or state a when-not-to-use condition, but the routing advice for prerequisites and the two lists is clear enough that an agent knows when to invoke it.

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

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/hermoso-ai/hermoso'

If you have feedback or need assistance with the MCP directory API, please join our Discord server