Skip to main content
Glama
Sign In
Unilytics MCP Server

Unilytics MCP Server

Official
by TeamUnilytics
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Remote

get_skill_proposal_diff

Read-only

Return the unified diff for one file changed by a skill proposal, comparing against the base or current skill version to show exactly what the proposal changes.

Instructions

Return the unified diff of one file a skill proposal changes (a new skill's files diff against nothing).

against="base" (default) compares with the skill version the agent read. When the proposal is stale (the skill
changed since), against="current" compares the proposal applied to the skill's current version, and
applies_to_current says whether it still applies. A long diff comes in pages of up to 40,000
characters as sent (JSON-escaped), with next_cursor. Use when the user wants to see exactly what a proposal changes in a file. Read-only.

Args:
    proposal_id: From list_skill_proposals (prp_…).
    target_id: A skill_id from the proposal's files (get_skill_proposal).
    path: That file's path, exactly as get_skill_proposal lists it.
    against: base (default) or current.
    cursor: next_cursor from the previous page of this diff.

Input Schema

NameRequiredDescriptionDefault
pathYes
cursorNo
againstNobase
target_idYes
proposal_idYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv1.1.0

TDQS

A4.7/5.0
Behavior5/5

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

Goes well beyond the readOnlyHint/destructiveHint/openWorldHint annotations by disclosing pagination behavior (pages of up to 40,000 characters as sent, JSON-escaped, with next_cursor) and the stale-proposal semantics including the applies_to_current signal. These are behavioral traits an agent could not infer from the structured fields.

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?

Content is front-loaded, starting with the one-sentence purpose before edge cases and parameters, and every clause carries information. However, the mid-sentence line breaks and the bulletless Args block make it slightly harder to scan than it needs to be.

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 explain the return value, and it does: a unified diff, its character-based pagination, and the applies_to_current flag. For a five-parameter read tool with an enum this is complete enough for an agent to call it correctly on the first attempt.

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?

Schema description coverage is 0%, so the description must carry parameter meaning, and it does: it names the ID prefix for proposal_id (prp_), explains that target_id is a skill_id taken from the proposal's files, insists path match get_skill_proposal's listing exactly, and defines both enum values of against plus the role of cursor. Every one of the five parameters is given meaning beyond its bare type.

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 a specific verb and resource ('Return the unified diff of one file a skill proposal changes') and scopes it to a single file, which clearly separates it from get_skill_proposal (which lists files) and list_skill_proposals (which lists proposals). The parenthetical about a new skill's files diffing against nothing removes ambiguity about the empty-base case.

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 an explicit trigger ('Use when the user wants to see exactly what a proposal changes in a file') and conditions for choosing against=base versus against=current, including the stale-proposal scenario. It also routes the agent to the right sources for identifiers (list_skill_proposals for proposal_id, get_skill_proposal for target_id/path), though it does not state when not to use 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