Skip to main content
Glama
Sign In

Mondovo

by com.mondovo.app
OverviewDiscussionsAdmin

Turn on a board's public share link

share_board
Destructive

Make a client's board publicly viewable and get back a shareable link you can hand the client — no Mondovo login needed. This is how you turn sharing ON from here (list_boards only reports whether a link already exists). Identify the board by board_id, or by site_id/client_id (uses that client's main board, or a named board via board_name). Set enabled: false to turn sharing off, or rotate: true to issue a fresh link that invalidates the old one. Optionally allow the client to vote (allow_votes) or comment (allow_comments) on options. Returns the public share_url (on the agency's own branded domain when configured) and whether sharing is on. The board must already exist — pin a design first if it doesn't.

Input Schema

NameRequiredDescriptionDefault
rotateNoIssue a new link, invalidating any previously shared one
enabledNoTurn sharing on (default) or off. Pass false to disable the public link.
site_idNoA site whose client's board to share (resolves the client for you)
board_idNoThe board to share (from list_boards). Alternative to site_id/client_id.
client_idNoAn explicit client id whose board to share (alternative to site_id)
user_goalNoOptional: the user's goal behind this call, in one short sentence of plain words (e.g. "add a page so customers can book tables"). No names, emails or other personal details.
board_nameNoShare a specific existing board by name (must already exist); otherwise the client's main board is used
allow_votesNoLet the client submit a preference/rating on the options
allow_commentsNoLet the client leave comments on the options

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • addedInput schema / properties / user_goal
      Added value: +{
+  "description": "Optional: the user's goal behind this call, in one short sentence of plain words (e.g. \"add a page so customers can book tables\"). No names, emails or other personal details.",
+  "type": "string"
+}
  2. First observed

TDQS

A4.6/5.0
Behavior4/5

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

Goes beyond the annotations by disclosing the key destructive side effect in plain terms — 'rotate: true to issue a fresh link that invalidates the old one' — which is exactly the risk destructiveHint:true flags. It also notes the link is public with 'no Mondovo login needed' and may be on the agency's branded domain. It stops short of stating permission requirements or whether disabling breaks existing embedded links, so not a 5.

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-loads the core action and return value, then moves to identification, then modifiers. One dense paragraph with essentially no filler, though the identifier-resolution clause is a bit compressed relative to its importance.

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?

Covers action, return payload (share_url plus whether sharing is on), client-facing semantics, the disable and rotate paths, permission scope of the link, and the board-must-exist precondition — all with no output schema to lean on. An agent has what it needs to call this correctly.

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 100%, so baseline is 3, but the description adds cross-parameter resolution logic the schema documents only piecemeal: board_id, or site_id/client_id resolving to 'that client's main board', or a named board via board_name. It also states the default for enabled (on) and the invalidation semantics of rotate.

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 ('Make a client's board publicly viewable and get back a shareable link') and immediately differentiates from sibling list_boards, which 'only reports whether a link already exists.' An agent can pick this over pin_design_to_board or list_boards without opening a schema.

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

Usage Guidelines5/5

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

Explicitly says 'This is how you turn sharing ON from here' and names the read-only alternative, plus gives a precondition ('pin a design first if it doesn't [exist]'). It also tells the agent which identifier combinations to use and what enabled:false / rotate:true are for.

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

All Mondovo toolsInspect
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