Moltline Creator Studio

This connector has been deprecated

Superseded listing, not a dead server. This entry was imported from an early Glama registration under com.moltlinestudio.mcp; the same server is listed under its official MCP Registry name — use com.moltlinestudio/creator. Endpoint unchanged: https://mcp.moltlinestudio.com/creator — still live, still free on the free tier. Only this duplicate entry is deprecated.

Get Free Skill

get_free_skill

Read-onlyIdempotent

Load a product's free gateway skill with its complete instructions. FREE.

Typical input {"slug": "brand-voice-keeper"} returns {"slug": "brand-voice-keeper", "skill": "", "instructions": ""}.

Returns exactly one skill - the product's free gateway skill - chosen automatically from the slug, with no plan required. Use when the caller wants usable instructions immediately. Not for the product's other skills: those are named and need get_full_skill with a skill_name, which requires a paid plan. Errors: on invalid, missing, or malformed input this tool never raises a protocol error; it returns {"error": ""} (for example {"error": "unknown slug ''. Use list_products."}). Every call is read-only and idempotent, so after correcting the input it is always safe to retry.

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": {
      "slug": "<slug>"
    },
    "name": "get_free_skill"
  }
}

Input Schema

Name	Required	Description	Default
`slug`	Yes	Product slug exactly as returned by list_products, e.g. "brand-voice-keeper".

Output Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedNov 10, 2026

changedInput schema / properties / slug / description

Previous value: -"Product slug exactly as returned by list_products,\ne.g. \"brand-voice\"."New value: +"Product slug exactly as returned by list_products,\ne.g. \"brand-voice-keeper\"."

First observedAug 17, 2026

TDQS

A4.4/5.0

Behavior4/5

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false, and openWorldHint=false, so the safety profile is covered. The description still adds value beyond them by disclosing that exactly one skill is returned, that selection is automatic, and that invalid input yields an {"error": ...} object rather than a protocol error. It does not describe the shape of the instructions payload beyond 'full skill text,' which is a minor gap.

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?

The purpose and the free/paid distinction are front-loaded, and the error-handling note is placed last where it belongs. The line-wrapped literal JSON blocks are somewhat visually noisy and could be tightened, but every sentence carries information an agent needs.

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 single-parameter, read-only lookup with an output schema, the definition covers purpose, routing, return shape, and error contract. An agent has everything required to call it correctly and to recover from bad input.

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 slug parameter already carries a description and the same 'brand-voice-keeper' example. The description's example input/output block restates that example and mainly illustrates the return mapping rather than adding new constraint or format detail about the parameter, so it lands at the baseline.

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?

The description opens with a specific verb and resource: 'Load a product's free gateway skill with its complete instructions.' It further narrows the scope by saying the skill is 'chosen automatically from the slug, with no plan required,' which cleanly separates it from the paid sibling that takes an explicit skill_name.

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?

It states when to use it ('when the caller wants usable instructions immediately') and when not to ('Not for the product's other skills'), and it names the alternative tool and its prerequisite: 'get_full_skill with a skill_name, which requires a paid plan.' The decision is fully routable without inference.

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

All Moltline Creator Studio 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.

Resources

Need Help?