Skip to main content
Glama
Sign In
Unilytics MCP Server

Unilytics MCP Server

Official
by TeamUnilytics
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Remote

list_skill_proposals

Read-only

Lists skill changes proposed by Unilytics agents for your skills or editable projects, newest first, so you can review pending proposals and the Agent Inbox.

Instructions

List the changes Unilytics' skill agents propose to the user's own skills and to the skills of projects the user can edit, newest first, 25 per page.

Use when the user asks what the agents have proposed, what is waiting for review, or about their Unilytics
proposals or Agent Inbox. Each entry has its proposal_id, kind (skill.edit = a change to the skill's files,
skill.flag = a finding with no change, skill.consolidate = merge similar skills into one, skill.retire = archive
skills, skill.trigger_conflict = new descriptions for skills that match the same tasks, skill.new_evals = new
eval cases, skill.new = a new skill), label, status, project_id (null = the user's own skills), title, the skills
it targets, revision, whether it is stale (a target skill changed since) and when it expires. Like the Agent
Inbox, it leaves out the agents' own maintenance items (new eval cases, requirement lists, rule fixes), so a
kind filter of skill.new_evals lists none, and a finding repeated across many of the user's skills. Read-only.

Args:
    status: open (default), dismissed, acknowledged, applied, reverted (applied, then undone), expired, or all.
    project_id: Only this project's proposals (from list_projects).
    kind: Only proposals of this kind.
    cursor: next_cursor from the previous page, with the same filters.

Input Schema

NameRequiredDescriptionDefault
kindNo
cursorNo
statusNoopen
project_idNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv1.1.0

TDQS

A4.6/5.0
Behavior5/5

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

Annotations already cover the read-only safety profile, but the description adds substantial behavior: newest-first ordering, 25-per-page pagination with cursor, and the non-obvious exclusion of agents' maintenance items (including the caveat that a skill.new_evals filter returns none). It also discloses the entry shape, staleness detection, and expiry, which an agent could not infer from the schema.

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 core purpose, then usage triggers, then return shape, then arguments — a sensible order. It is dense, particularly the long kind enumeration, but each item conveys semantics the agent needs when filtering; minor trimming of repeated 'skill.' prefixes would help.

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?

With no output schema, the description compensates by enumerating returned fields (proposal_id, kind, label, status, project_id, title, targeted skills, revision, stale, expiry). Combined with pagination and filter semantics for all four parameters, nothing essential for correct invocation is missing.

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 description coverage is 0%, so the description carries the full burden and mostly does: it explains each status value (including 'reverted (applied, then undone)'), that project_id comes from list_projects and null means the user's own skills, and that cursor is the previous page's next_cursor used with identical filters. It also gives semantic meaning to each kind enum value rather than just repeating them.

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?

Names a specific verb (List) and resource (changes skill agents propose), scopes it to the user's own skills plus projects the user can edit, and states ordering and page size (newest first, 25 per page). This is well beyond a restatement of the name and lets an agent know exactly what it retrieves.

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?

Explicitly lists triggering intents: 'what the agents have proposed', 'what is waiting for review', 'Unilytics proposals or Agent Inbox'. It also points to list_projects as the source of project_id. It does not name siblings like get_skill_proposal or get_skill_proposal_diff as alternatives for drilling into a single proposal, so exclusions are implied rather than stated.

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