Mobbin

Save Content

save_content

Idempotent

Save screens, flows or website sections for the user's Mobbin MCP connection. Pass collection_id: "all-saved" to save to All saved, or a collection id from list_collections or create_collection to save to that collection, which also saves to All saved. Only the user and their teammates see saved items, unless that collection is public. Use ids from another Mobbin tool's result, like search or get_collection_contents, or the ids (UUIDs) in Mobbin links the user shares. Never guess or make up an id. Use it only when the user asks to save, keep or collect items, never to remember results for yourself. An item already saved there is left as it is. All or nothing: on an error nothing is saved. Fix what the error names and send the same request again, which is always safe.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "collection_id": "<collection_id>",
      "contents": "<contents>"
    },
    "name": "save_content"
  }
}

Input Schema

Name	Required	Description
`contents`	Yes	The items to save.
`task_intent`	No	One short sentence summarizing the user's overall task. Helps return more relevant results. Write it in English even when the conversation is in another language. MUST be the same across all calls for the same task. Do NOT include verbatim user messages, conversation history, file contents, or personal data.
`collection_id`	Yes	A collection id from list_collections, or "all-saved" for everything saved for the user's Mobbin MCP connection.

Output Schema

Name	Required	Description	Default
`mobbin_url`	Yes	Link to open it on Mobbin.

Schema Changelog

Changes observed during successful MCP inspections.

AddedOct 23, 2026

TDQS

A4.8/5.0

Behavior5/5

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

Annotations only declare readOnly=false, idempotent=true and destructive=false; the description goes further by stating visibility (user and teammates only, unless the collection is public), dedupe behavior ("an item already saved there is left as it is") and transactionality ("All or nothing: on an error nothing is saved"). It even explains safe retry after an error, which no annotation covers.

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-loaded with purpose, then the collection_id rule, then id sourcing, then the use gate and error semantics — a sensible order. Dense but nearly every clause carries a distinct constraint; only the closing error-recovery sentence could be trimmed.

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?

An output schema exists, so return values need no explanation. For a null-destructive mutation with three params, the description covers visibility, idempotency, atomicity, retry safety and id provenance — everything an agent needs to call it 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 the baseline is 3, but the description adds real meaning: that a specific collection also implies saving to All saved, and that ids must never be invented. It says nothing about the optional task_intent parameter, leaving that entirely to the schema.

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?

Opens with a specific verb and resource set ("Save screens, flows or website sections") scoped to the user's Mobbin MCP connection. It distinguishes itself from siblings by naming list_collections, create_collection, search flows and get_collection_contents as id sources rather than as alternatives for this action.

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 use condition ("only when the user asks to save, keep or collect items") and an explicit exclusion ("never to remember results for yourself"). It also routes the agent to the right upstream tools for ids and tells it where ids come from when the user shares a Mobbin link.

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

All Mobbin tools Inspect

Try in Browser

Claude Code, inside the Godot 4 editorFlockbay puts an AI agent in the real Godot 4 editor: it writes GDScript, runs your game and fixes what breaks. Free, or bring your own Claude Code or Codex.flockbay.comAd

Glama MCP Gateway

Add one secure layer between your agents and this server.