Skip to main content
Glama

socialclaw

by io.github.ndesv21
OverviewDiscussionsAdmin

Upload asset

upload_asset

Add an image or video to the user's SocialClaw media library so it can be attached to a post. Pass exactly one of: file (a file the user attached in this chat), sourceUrl (a direct public http(s) link to the image or video file, not a web page), or contentBase64 (small files only). Files up to 1 GB are supported through file or sourceUrl. The result is the asset: when status is ready, use its publicUrl as media_link in validate_schedule/apply_schedule. Large videos may come back with status uploading; then call get_asset with the asset id until status is ready (or failed) before scheduling.

Input Schema

NameRequiredDescriptionDefault
fileNoA file the user attached in the conversation.
filenameNoOptional filename including extension, e.g. launch.png. Inferred from the file or URL when omitted.
sourceUrlNoDirect public http(s) URL of the image or video file.
contentBase64NoBase64-encoded file content. Small files only; prefer file or sourceUrl.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed5 schema fields changed
    • changedInput schema / properties / contentBase64 / description
      Previous value: -"Base64-encoded file content (alternative to sourceUrl)."New value: +"Base64-encoded file content. Small files only; prefer file or sourceUrl."
    • addedInput schema / properties / file
      Added value: +{
+  "description": "A file the user attached in the conversation.",
+  "properties": {
+    "download_url": {
+      "description": "Temporary download URL of the attached file.",
+      "type": "string"
+    },
+    "file_id": {
+      "description": "Id of the attached file.",
+      "type": "string"
+    },
+    "file_name": {
+      "description": "Original name of the attached file, if known.",
+      "type": "string"
+    },
+    "mime_type": {
+      "description": "Mime type of the attached file, if known.",
+      "type": "string"
+    }
+  },
+  "required": [
+    "download_url",
+    "file_id"
+  ],
+  "type": "object"
+}
    • changedInput schema / properties / filename / description
      Previous value: -"Filename including extension, e.g. launch.png."New value: +"Optional filename including extension, e.g. launch.png. Inferred from the file or URL when omitted."
    • changedInput schema / properties / sourceUrl / description
      Previous value: -"Public http(s) URL of the image or video."New value: +"Direct public http(s) URL of the image or video file."
    • removedInput schema / required
      Removed value: -[
-  "filename"
-]
  2. Changed1 schema field changed
    • changedInput schema / properties / sourceUrl / description
      Previous value: -"Public URL to download the media from."New value: +"Public http(s) URL of the image or video."
  3. First observed

TDQS

A4.9/5.0
Behavior5/5

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

Annotations only state the generic safety profile (readOnly=false, idempotent=false, openWorld=true); the description adds real behavior: the exactly-one-of input constraint, the 1 GB size ceiling via file/sourceUrl, and the asynchronous status lifecycle (ready/uploading/failed) with a polling remedy via get_asset. This is context the annotations cannot convey.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loaded with purpose, then input constraint and size limit, then the result/next-step workflow. Dense and every sentence carries an actionable fact with no filler.

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 4-param tool with a nested object, no output schema, and mutating semantics, the description supplies the input contract, size limits, return shape (status/publicUrl), and the async polling path. An agent has everything needed to call it and act on the result.

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. The description still adds value beyond the schema: the mutually exclusive 'exactly one of' rule, the 'file the user attached in this chat' scoping, and the 'not a web page' clarification for sourceUrl. It stops short of explaining when filename inference applies, but covers the load-bearing semantics.

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 ('Add an image or video to the user's SocialClaw media library') and ties it to the goal ('so it can be attached to a post'). An agent can distinguish it from list_assets/get_asset without inspecting schemas.

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?

Gives an explicit selection rule ('Pass exactly one of: file, sourceUrl, or contentBase64') with the condition differentiating them, and routes the agent downstream to validate_schedule/apply_schedule and to get_asset when status is uploading. When-to-use and follow-up actions are both pinned down.

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

All socialclaw 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