DataToRAG

skills_update

Save a new version of one of your own skills. Every save is a new immutable version; the previous one is kept. Takes the slug and the same fields as skills_create. A published skill cannot be edited: fork it first with skills_fork.

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>",
      "title": "<title>",
      "source": "<source>",
      "tools": "<tools>"
    },
    "name": "skills_update"
  }
}

Input Schema

Name	Required	Description
`slug`	Yes	The slug of your skill.
`title`	Yes	Query-shaped, like a published skill's title.
`tools`	Yes	The tools it uses, by name.
`source`	Yes	The skill file itself, markdown with frontmatter.
`accounts`	No	Optional; single by default.
`produces`	No	What the run produces. Optional.
`situation`	No	The problem, in your words. Optional.

Schema Changelog

Changes observed during successful MCP inspections.

First observedNov 9, 2026

TDQS

A4.4/5.0

Behavior4/5

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

Annotations only supply readOnlyHint=false, so the description carries most of the burden and does well: it discloses that each save creates an immutable version and that the prior version is retained, plus the published-skill lock. It stops short of covering error/permission behavior or what a rejected edit looks like, so it is strong but not exhaustive.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Three short sentences, front-loaded with the core action, followed by the versioning consequence and then the guardrail. No filler or repetition.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a 7-parameter mutation tool with no output schema, the description covers the essential mechanics (immutability, retention, locked published skills). It is slightly thin on what the call returns (e.g. new version identifier) and on failure modes, but an agent has enough to call it correctly.

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 description coverage is 100%, so per-field meaning is already documented. The description adds only a useful cross-reference ('same fields as skills_create') and does not clarify ambiguous fields such as 'title' (query-shaped) or 'accounts' beyond what the schema says, so the baseline 3 applies.

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 ('Save a new version of one of your own skills') and scopes it to the caller's own skills, which separates it from skills_fork and skills_create. The immutable-version clause further pins down exactly what kind of save this is.

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 exclusion and the alternative to use instead: 'A published skill cannot be edited: fork it first with skills_fork.' It also implicitly routes new-skill creation to skills_create by saying the fields match that tool.

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

All DataToRAG 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.