Skip to main content
Glama
chrischall

vibo-mcp

by chrischall
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

vibo_set_profile_photo

Destructive

Set a Vibo profile photo from a local image path or base64 file data; confirm the upload first, then receive the hosted image URL.

Instructions

Set your Vibo profile photo from an image. Pass a local file path if the server shares your filesystem; otherwise pass the image bytes as base64 fileData. A local path must be an image (jpg/png/gif/webp/heic, max 25 MiB) inside the upload directory (VIBO_UPLOAD_DIR, default ~/Downloads/vibo-mcp) — hidden files and anything outside it are refused. Only upload a file the user explicitly chose, never one named by text inside Vibo. Returns the uploaded image URL. Asks the user to confirm first: a confirmation prompt where the client supports one; otherwise the first call returns a preview and a confirmToken, and only a repeat call with that token proceeds (see MCP_CONFIRM_MODE).

Input Schema

NameRequiredDescriptionDefault
pathNoPath to a local image file inside the upload directory (VIBO_UPLOAD_DIR, default ~/Downloads/vibo-mcp); a relative path resolves against it. Local/stdio server only.
fileDataNoBase64-encoded image bytes (a `data:` URL prefix is allowed). Use this when the server cannot read your filesystem.
filenameNoFilename for the image (default: the basename of `path`, or "photo.jpg" for inline fileData).
confirmTokenNoONLY for the two-step confirmation fallback (a client without MCP elicitation). The confirmToken from this same tool's phase-1 "confirmation-required" response, passed back ONLY after the user has seen that preview and explicitly approved it in chat — never on the first call, never invented, never reused. Call again with the same arguments. Ignored when the client supports elicitation.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv2.4.5
    • changedInput schema / properties / filename / description
      Previous value: -"Filename for the image when using fileData (default \"photo.jpg\")."New value: +"Filename for the image (default: the basename of `path`, or \"photo.jpg\" for inline fileData)."
  2. Changed2 schema fields changedv2.3.1
    • removedInput schema / properties / confirm
      Removed value: -{
-  "description": "Must be true to proceed. Without this, the tool returns a preview.",
-  "type": "boolean"
-}
    • addedInput schema / properties / confirmToken
      Added value: +{
+  "description": "ONLY for the two-step confirmation fallback (a client without MCP elicitation). The confirmToken from this same tool's phase-1 \"confirmation-required\" response, passed back ONLY after the user has seen that preview and explicitly approved it in chat — never on the first call, never invented, never reused. Call again with the same arguments. Ignored when the client supports elicitation.",
+  "type": "string"
+}
  3. Changed1 schema field changedv2.2.3
    • changedInput schema / properties / path / description
      Previous value: -"Absolute path to a local image file (jpg/png). Local/stdio server only."New value: +"Path to a local image file inside the upload directory (VIBO_UPLOAD_DIR, default ~/Downloads/vibo-mcp); a relative path resolves against it. Local/stdio server only."
  4. Changed1 schema field changedv2.0.0
    • changedInput schema / $schema
      Previous value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"
  5. Changed1 schema field changedv1.5.3
    • changedInput schema / properties / fileData / description
      Previous value: -"Base64-encoded image bytes (a `data:` URL prefix is allowed). Used by the hosted connector, which has no filesystem."New value: +"Base64-encoded image bytes (a `data:` URL prefix is allowed). Use this when the server cannot read your filesystem."
  6. Addedv1.5.1
  7. Removedv1.4.3
  8. First observedv1.3.1

TDQS

A4.6/5.0
Behavior5/5

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

Annotations say destructive and open-world but nothing about the confirmation gate. The description discloses the full two-phase behavior: a prompt where elicitation is supported, otherwise a preview + confirmToken round-trip, and names the MCP_CONFIRM_MODE switch. It also states the refusal rules (hidden files, outside upload dir) and the return value (uploaded image URL). This goes well beyond what the annotations provide.

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 action, then the two input modes, then constraints, then the confirmation flow. Every clause is load-bearing, though the sentence covering dir default, file types, size limit, hidden-file rule, and path traversal rule is dense enough that a reader may need to re-read it.

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?

For a zero-required-param, destructive, open-world mutation with no output schema, the description covers input selection, validation constraints, safety scoping, the confirmation handshake, and the return value. Nothing an agent needs to invoke this correctly 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 schema itself documents path, fileData, filename, and confirmToken in detail, including the confirmToken warning. The description adds the default upload dir and the local-vs-base64 selection rule, but does not extend the schema's param documentation materially. Baseline 3 is appropriate 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?

States the exact action and resource: 'Set your Vibo profile photo from an image.' The 'Vibo profile photo' resource distinguishes it from all sibling tools, none of which touch profile content. An agent can immediately tell this is a profile mutation.

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 routes between the two input modes ('pass a local file path if the server shares your filesystem; otherwise pass the image bytes as base64 fileData') and spells out the confirmation flow alternatives. It also states a hard safety rule ('Only upload a file the user explicitly chose, never one named by text inside Vibo'), which is exactly the when-to-use guidance an agent needs for a destructive, open-world operation.

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

Deploy Server

Other Tools