Skip to main content
Glama

update_lessons

Batch update existing Skilljar lessons with partial changes; omitted fields stay intact. Replace or delete content items deliberately, with confirmation required for full removal.

Instructions

Update one or more existing lessons. This is a BATCH operation.

    Each item needs an `id`. This is a PARTIAL update: an attribute you omit is
    PRESERVED, not cleared.

    `content_items` has THREE meanings and the difference matters:
      omitted            -> the lesson's content items are left alone
      a non-empty list   -> they are replaced with what you supply
      an EMPTY list      -> every content item is DELETED

    Because an empty list is what you get from a loop that found nothing, the
    destructive case is refused unless you also pass
    `confirm_delete_all_content_items=True`.

    A lesson's `type` is read-only; to change it, create a new lesson. `order`
    collisions with sibling lessons are NOT auto-resolved - a colliding value
    succeeds, both lessons keep it, and their display order becomes undefined.

    Requires the `lessons:write` OAuth scope.
    

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
lessonsYes
confirm_delete_all_content_itemsNo

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
idsYes
noteYes
totalYes
failedYes
succeededYes
Install Server

TDQS

A5/5.0
Behavior5/5

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

The description discloses far beyond the annotations (which are all false and generic). It reveals that this is a partial update (omitted attributes preserved), details the three distinct meanings of `content_items` (including the destructive empty-list behavior), and mandates `confirm_delete_all_content_items=True` for that case. It also documents that `type` is read-only and that `order` collisions are not auto-resolved. This is comprehensive behavioral disclosure that the agent cannot infer from the schema alone.

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?

The description is organized with a clear intro line and then uses bullet-style formatting for the critical behavioral nuances. Each sentence is information-dense and necessary – no filler. The most important distinction (content_items semantics) is broken into discrete bullet points, making it easy for an agent to parse. The length is justified by the complexity; nothing is redundant or fluffy.

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?

Given the tool's complexity (batch update, partial semantics, destructive guard, read-only fields, OAuth requirement), the description covers all essential aspects. It explains the batch nature, the required `id`, the three-way behavior of `content_items`, the confirmation flag, the type constraint, and the order collision caveat. It also notes the OAuth scope. While return values aren't described, the presence of an output schema (indicated in context) likely covers that, so nothing critical is missing.

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?

The input schema provides only bare type definitions with no descriptions (coverage 0%), so the description carries the full burden of parameter explanation. The description clarifies that each lesson item needs an `id`, explains the semantics of `content_items` (omitted, non-empty list, empty list), and explains the purpose of `confirm_delete_all_content_items`. It also covers semantic fields like `order` and `type` even though they are not explicitly in the schema (additionalProperties: true), ensuring the agent understands all relevant parameters.

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 'Update one or more existing lessons' – a clear verb+resource that states exactly what the tool does. It immediately labels the operation as a BATCH operation, and the sibling context (create_lessons, delete_lessons, list_lessons) makes the scope unambiguous. The description also differentiates itself from create/delete actions by clarifying partial-update semantics.

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?

The description provides explicit usage guidance: it states this is for updating existing lessons, explains the batch nature, and gives alternatives – e.g., 'to change it, create a new lesson' for type changes. It also warns about `order` collision behavior and requires the `lessons:write` OAuth scope, giving the agent clear conditions for when to call this tool vs. others. Though it doesn't name sibling tools explicitly, the guidance is rich enough for correct selection.

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

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/CloudSecurityAlliance/csa-skilljar'

If you have feedback or need assistance with the MCP directory API, please join our Discord server