JobMojito

Create, rename or delete a media folder

manage_media_folder

Destructive

[Admin] Create an empty folder, rename one, or delete an empty one. Renaming moves every file in it to a new address: live pages keep the old one and page drafts move at once. A folder is deleted only once its files are moved or deleted. Names: 1 to 60 letters, digits, spaces, "-", "", ".", "(" and ")"; not starting with ".", "" or a space, and never "profile".

Every argument in full, with examples: get_tool_reference.

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": {
      "action": "<action>",
      "folder": "<folder>"
    },
    "name": "manage_media_folder"
  }
}

Input Schema

Name	Required	Description
`to`	No	The new name. Required to rename.
`action`	Yes	`create` an empty folder, `rename` one with every file in it, or `delete` an empty one.
`folder`	Yes	The folder to create, rename or delete.
`llm_model`	No	Your model id, e.g. "claude-opus-4-8"; "unknown" if unsure. For analytics.
`merchant_id`	No	Optional company. Admins and sub-merchant operators only; other callers always use their token's company.
`conversation_id`	No	The conversation_id this server returned earlier in this conversation, unchanged, including after later user messages. Omit it if you have none. Recorded for the server developer's analytics.

Output Schema

Name	Required	Description
`moved`	No
`folder`	Yes
`warnings`	No
`drafts_updated`	No
`_mcp_instructions`	No	Server-issued metadata for this conversation.

Schema Changelog

Changes observed during successful MCP inspections.

Changed9 schema fields changedNov 9, 2026

removedInput schema / properties / action / example
```
Removed value: -"create"
```
removedInput schema / properties / folder / example
```
Removed value: -"Crew life"
```

addedInput schema / properties / llm_model

Added value: +{
+  "description": "Your model id, e.g. \"claude-opus-4-8\"; \"unknown\" if unsure. For analytics.",
+  "type": "string"
+}

removedInput schema / properties / merchant_id / example

Removed value: -"28106cba-1c27-4e53-b149-32113e5e8e31"

removedInput schema / properties / to / example
```
Removed value: -"Life on board"
```

removedOutput schema / properties / drafts_updated / description

Removed value: -"Rename only: page drafts moved to the new addresses. Published pages keep the old ones until they are published again."

removedOutput schema / properties / folder / description

Removed value: -"The folder as it is now: the new name after a rename."

removedOutput schema / properties / moved / description

Removed value: -"Rename only: files moved to the new folder."

removedOutput schema / properties / warnings / description

Removed value: -"Rename only: things worth telling the person. The folder was renamed."

AddedNov 8, 2026

TDQS

A4.1/5.0

Behavior4/5

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

Annotations already declare destructiveHint=true and idempotentHint=false, but the description adds real behavioral detail annotations cannot: renaming moves all contained files to a new address, live pages retain the old address while drafts move immediately, and deletion is blocked until contents are moved or removed. The draft/live-page sentence is slightly cryptic, which keeps it from 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-loaded with the three actions, then constraints, then the naming rules and a reference pointer. Every sentence carries weight, though the naming-rules sentence is dense and the 'page drafts move at once' phrasing could be sharper.

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 destructive, admin-scoped mutation tool with an output schema and full annotation coverage, the description covers authorization, side effects, preconditions, and name validation. Minor gaps remain around what a create returns and whether a parent location is implied, but nothing critical is missing for correct invocation.

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%, so all six parameters are already documented in the schema; the 3 baseline applies. The description does add naming constraints for the folder/new-name values (length 1-60, allowed character set, forbidden leading characters, reserved name 'profile') and routes agents to get_tool_reference for detailed argument examples.

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 three concrete verbs on a specific resource ('Create an empty folder, rename one, or delete an empty one'), and the '[Admin]' prefix plus 'empty' qualifier set the scope. The folder/media domain is clearly distinct from the file-oriented siblings (manage_media_file, list_media_files, start_media_upload).

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

Usage Guidelines4/5

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

Gives clear preconditions: admin only, rename relocates every contained file, delete only succeeds once the folder is empty. It does not explicitly point to alternative tools (e.g. manage_media_file for files within a folder) or say when to prefer rename over delete-and-recreate, so it stops short of a full when/when-not routing.

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

All JobMojito tools Inspect

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.