Skip to main content
Glama
Unilytics MCP Server

Unilytics MCP Server

Official

create_skill

Save a new editable SKILL.md playbook for a user or project, or seed a copy from an existing skill to customize and share a method with a client team.

Instructions

Save a new editable skill (a SKILL.md playbook) for the user or one of their projects.

Use when the user asks to create a skill, save a method as a skill, customize a built-in or
Unilytics skill, or share one of their own personal skills with a client team by copying it into
that client's project (extends="<skill_id>" seeds the copy with that skill's files). Reference and
data files are added afterwards with update_skill. Refuses a name the owner already uses, and a
skill_markdown whose frontmatter (name and description between --- lines) is missing or broken
(invalid YAML, a repeated key, not key: value lines, a requires: block that isn't schema 1), or
whose description is over 1,024 characters (skill_md_invalid). The result's `lint`
lists authoring findings on the saved skill (lint-v1 rule ids, each with a message and a fix);
findings don't stop the save.

File layout (a skill is SKILL.md plus supporting files):
  - SKILL.md        the workflow and its definition of done; short, linking to the files below.
  - reference/*.md  documents read when a step needs them (style guides, pipelines).
  - data/*          assets the skill carries, including runnable scripts such as a
                    data/verify_row.py checker; get_skill lists them as data_files.

Args:
    name: Skill name: the title people see (unless SKILL.md sets metadata.title); its slug is the
        last part of the skill id. Required.
    skill_markdown: The SKILL.md contents (frontmatter + workflow). Required
        unless `extends` is given (then it's seeded from the built-in, but you
        may override).
    description: Short description (else taken from frontmatter).
    category: Category label (e.g. "seo", "content").
    scope: "user" (private to you) or "project" (shared with collaborators).
    project_id: Required when scope="project".
    extends: The skill to copy as the starting point: a built-in id, a Unilytics skill id, or the id
        of one of the user's own personal skills (user/…). A Unilytics skill's approved version and a
        personal skill's current version are copied with all their files; a built-in (by its exact id,
        with skill_markdown left empty) is copied with its reference and data files. A personal skill
        copied with scope="project" is shared with that project's team, and the result's `copied_from`
        names the version copied. Project skills aren't copied, and a project copy whose files name
        skills outside that project (personal or another project's) is refused.
    visibility: "private" | "project" | "public".
    verbatim_source: When porting an existing document, its original text. The store runs a
        coverage-based fidelity check and returns a report: FAIL means content was condensed or
        dropped; splitting and intentional edits pass. author_skill returns the full authoring guide.

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": {
      "name": "<name>",
      "skill_markdown": "<skill_markdown>"
    },
    "name": "create_skill"
  }
}

Input Schema

NameRequiredDescriptionDefault
nameYes
scopeNouser
extendsNo
categoryNo
project_idNo
visibilityNoprivate
descriptionNo
skill_markdownYes
verbatim_sourceNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv1.1.0
    • removedInput schema / properties / config
      Removed value: -{
      -  "default": null,
      -  "title": "config",
      -  "type": "string"
      -}
  2. First observedv1.0.0

TDQS

A4.9/5.0
Behavior5/5

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

Goes well beyond the annotations, which only say it is a non-read-only, non-destructive, non-idempotent write. It enumerates hard refusal conditions (duplicate owner name, missing/broken frontmatter, invalid YAML, repeated key, bad requires: block, description over 1,024 characters → skill_md_invalid) and clarifies that lint findings are advisory and do not block the save. It also explains the file layout written, how extends seeds copies from built-ins/Unilytics/personal skills, and the cross-project reference refusal.

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 correctly: purpose, then when-to-use, then refusal behavior, then file layout, then per-argument detail. Almost every sentence carries operational value, but the refusal clause is a single dense run-on and the file-layout block is somewhat verbose for a tool description, costing a point on tightness.

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?

A nine-parameter, no-output-schema, mutation tool with zero schema coverage — exactly the case where the description must do everything. It documents all inputs, explains the returned artifacts (result.lint with lint-v1 rule ids, copied_from version), and warns about the verbatim_source FAIL report, leaving no material gap for correct invocation.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

With 0% schema description coverage across nine parameters, the description carries the full burden and does so: name (title shown, slug becomes the skill id tail), skill_markdown (required unless extends seeds it, overridable), scope/project_id coupling, extends (accepted id forms, what version is copied, what is refused), visibility values, and verbatim_source with its coverage-based fidelity report semantics. Each parameter gets meaning the raw schema does not convey.

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+resource plus a parenthetical definition of what a skill actually is ('a SKILL.md playbook'), and scopes it to 'the user or one of their projects'. It distinguishes itself from the nearest siblings by name, noting that reference/data files come later via update_skill and that author_skill returns the authoring guide.

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 four-way when-to-use list (create a skill, save a method, customize a built-in/Unilytics skill, share a personal skill into a client project) with the mechanism for the last case (extends="<skill_id>"). It also states exclusions and alternatives: project skills can't be copied, and file additions belong to update_skill rather than this tool.

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