Skip to main content
Glama
Sign In
Unilytics MCP Server

Unilytics MCP Server

Official
by TeamUnilytics
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Remote

list_skills

Read-only

Browse saved SEO, content, and AEO/GEO playbooks by category—built-in, Unilytics, personal, and project—so you can choose the right skill for a task.

Instructions

List every skill the user can use: their saved step-by-step playbooks for SEO, content and AEO/GEO work.

Returns the built-in skills grouped by category (seo, content, geo), the skills provided by
Unilytics (read-only) and the user's own and project skills, each with its skill_id, name and
description (the first 200 characters; get_skill has the rest). Use when the user wants to browse
or choose from their skills; find_skill ranks them against one task. Each of the user's own and
project skills has `your_role`: owner, admin or editor can change it, viewer can use it; a project
skill whose role isn't owner is one shared with the user. `total_skills` counts all of them;
`next_cursor` (when set) is passed back as `cursor` for the next page.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "list_skills"
  }
}

Input Schema

NameRequiredDescriptionDefault
cursorNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changedv1.1.0
    • removedInput schema / properties / config
      Removed value: -{
-  "default": null,
-  "title": "config",
-  "type": "string"
-}
    • addedInput schema / properties / cursor
      Added value: +{
+  "default": null,
+  "title": "Cursor",
+  "type": "string"
+}
  2. First observedv1.0.0

TDQS

A4.8/5.0
Behavior5/5

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

Annotations already declare readOnlyHint=true and destructiveHint=false, but the description adds a lot on top: the three result groupings (built-in by category, Unilytics read-only, user/project), the returned fields, the 200-character truncation of descriptions, the meaning of `your_role` and its permission implications, and the `total_skills`/`next_cursor` pagination contract. The read-only Unilytics hint also implicitly explains why a bundled skill can't be edited.

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?

Purpose, alternative-routing, return shape and pagination each get their own sentence and are front-loaded, so the scanning order is right. The `your_role` sentences are dense and lean on parenthetical asides, making the middle section slightly heavier than it needs to be for a one-parameter list tool.

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?

There is no output schema, so the description must describe returns, and it does: groupings, field list, truncation behavior, role semantics, and the total/cursor pair. For a single optional cursor parameter on a read-only tool this leaves nothing material an agent needs in order to call it and interpret the result 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?

The schema documents no parameter text at all (0% coverage), only a nullable string defaulting to null, so the description carries the full burden and does: it explains that `next_cursor` from a prior response is passed back as `cursor` for the next page. It does not explicitly state that omitting cursor starts from page one or hint at page size, which keeps it just short of full coverage.

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 ("List every skill the user can use") and immediately defines the domain in plain terms ("saved step-by-step playbooks for SEO, content and AEO/GEO work"). It also distinguishes itself from the two nearest siblings by naming find_skill (ranking) and get_skill (full description), so an agent can separate this tool from its lookalikes without reading any schema.

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 the selection condition explicitly: "Use when the user wants to browse or choose from their skills; find_skill ranks them against one task." That is a direct when-to-use plus the alternative that takes over when the intent is task-matching, and get_skill is flagged as the follow-up for full text.

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