Skip to main content
Glama

Auth.Set Link Visibility

auth.set_link_visibility

Set the public/private visibility of an affiliate link within a product.

Public links appear in the product's Affilio storefront listing; private links are hidden. Visibility is scoped to the product the link belongs to.

Requires Bearer token authentication.

Technical reference: https://affilio.link/blog/mcp-for-everyone

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
link_idYesLink ID returned by auth.create_link or auth.list_links.
product_idYesProduct ID that owns this link. Returned by auth.create_product or auth.get_product.
visibilityYesVisibility setting for the link. Accepted values: 'public' — link is visible in the product's storefront listing; 'private' — link is hidden from storefront listings.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections. Dates show when Glama detected each change.

  1. Changed2 schema fields changed
    • changedInput schema / properties / link_id / description
      Previous value: -"Unique link ID (MongoDB ObjectId string) of the link whose visibility to change."New value: +"Link ID returned by auth.create_link or auth.list_links."
    • changedInput schema / properties / product_id / description
      Previous value: -"Unique product ID (MongoDB ObjectId string) that the link belongs to. Link visibility in Affilio is managed per product; retrieve via auth.create_product or auth.get_product."New value: +"Product ID that owns this link. Returned by auth.create_product or auth.get_product."
  2. Changed3 schema fields changed
    • addedInput schema / properties / product_id
      Added value: +{
      +  "description": "Unique product ID (MongoDB ObjectId string) that the link belongs to. Link visibility in Affilio is managed per product; retrieve via auth.create_product or auth.get_product.",
      +  "type": "string"
      +}
    • changedInput schema / properties / visibility / description
      Previous value: -"Visibility setting for the link. Accepted values: 'public' — link is accessible to anyone with the short URL and appears in storefront listings; 'private' — link is hidden from public access and storefront listings, only visible to the account owner."New value: +"Visibility setting for the link. Accepted values: 'public' — link is visible in the product's storefront listing; 'private' — link is hidden from storefront listings."
    • changedInput schema / required
      Previous value: -[
      -  "link_id",
      -  "visibility"
      -]New value: +[
      +  "product_id",
      +  "link_id",
      +  "visibility"
      +]
  3. Changed2 schema fields changed
    • addedInput schema / properties / link_id / description
      Added value: +"Unique link ID (MongoDB ObjectId string) of the link whose visibility to change."
    • addedInput schema / properties / visibility / description
      Added value: +"Visibility setting for the link. Accepted values: 'public' — link is accessible to anyone with the short URL and appears in storefront listings; 'private' — link is hidden from public access and storefront listings, only visible to the account owner."
  4. Added

TDQS

A3.7/5.0
Behavior3/5

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It does disclose the visible effect on the storefront, the product scoping, and the auth requirement. However, it does not mention whether the operation is reversible, whether setting a link private removes an existing storefront display immediately, or what relevant state changes occur on the server. For a mutation tool with zero annotation coverage, this is adequate but not thorough.

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 broken into short, readable paragraphs with the main action front-loaded and supporting context (scoping, auth) following in order of importance. The only extraneous element is the trailing technical-reference URL, which adds little for tool-selection and slightly dilutes the focus, but overall the text is efficient and well-structured.

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 moderate-complexity mutation with an output schema and fully-documented parameters, the description is fairly complete: it covers purpose, scoping, and authentication. Minor gaps remain — it does not address idempotency (setting visibility to its current value) or the immediacy of the storefront update — but the presence of an output schema relieves the need to explain return values, so nothing essential to a correct call is missing.

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 description coverage is 100%, so the schema already documents all three parameters well, giving a baseline of 3. The description adds genuine meaning on top by explaining the real-world consequence of the visibility values ('Public links appear in the product's Affilio storefront listing; private links are hidden'), which enriches the visibility parameter's semantics beyond the schema's value definitions.

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 specific verb-plus-resource ('Set the public/private visibility of an affiliate link within a product') and immediately clarifies the practical effect: public links appear in the storefront listing, private links are hidden. This distinguishes it from the sibling auth.update_link, which would presumably handle broader attribute changes, so an agent can clearly differentiate this tool's focused scope.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description states the scoping constraint ('Visibility is scoped to the product the link belongs to') and the authentication prerequisite (Bearer token), but it gives no when-to-use vs when-not-to-use guidance and names no alternatives. An agent is left to infer when this tool is preferable to auth.update_link or auth.archive_link, so selection guidance is essentially absent.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A3.9/5.0
Disambiguation4/5

Most tools map cleanly to distinct resources and actions, but auth.create_link vs shorten_url and check_url vs check_international_redirect have overlapping purposes. The descriptions do a good job of clarifying the differences, so ambiguity is limited.

Naming Consistency4/5

All names follow a readable snake_case verb_noun pattern, but auth.* tools are prefixed while utility tools like check_url, generate_qr, and shorten_url are not. Names like list_links and list_links_ranked are also close, though still predictable.

Tool Count3/5

20 tools is on the heavy side for this domain. Most cover distinct functions, but there is some redundancy such as list_links_ranked being a sorting variant of list_links and shorten_url overlapping with auth.create_link.

Completeness3/5

Link lifecycle coverage is solid: create, get, list, update, archive, stats, and visibility are all present. However, product management is incomplete with no update/delete/remove-link operations, and there is no unarchive or hard-delete for links.

Resources