Underlayer

Update course

update_course

DestructiveIdempotent

Partially updates a course by id. Every field besides id is optional — send only what changes.

Input Schema

TableJSON Schema

Name	Required	Description
`id`	Yes	The course id, as returned by list_courses or create_course.
`title`	No	New course title. Omit to leave it unchanged.
`status`	No	'published' makes the course live to learners; 'draft' takes it out of circulation. Omit to leave it unchanged.
`screens`	No	Replaces the whole screens array; it is not merged screen by screen. To change one screen, prefer update_screen. Omit to leave screens unchanged.
`themeId`	No	Id of a theme in this workspace to assign; null removes the theme. Omit to leave it unchanged.
`direction`	No	Reading direction of the course: 'ltr' or 'rtl'. Omit to leave it unchanged.
`navigation`	No	'default' shows the player's Back/Continue row; 'hidden' removes it (and swipe) so button blocks move the learner on. Omit to leave it unchanged.
`passingScore`	No	Percentage (0-100) of graded blocks a learner must answer correctly to pass; null means any completion counts. Omit to leave it unchanged.
`quizFeedback`	No	When learners see whether an answer was right: 'deferred' (at the end) or 'immediate' (as they answer). Omit to leave it unchanged.
`certificateId`	No	Id of a certificate template in this workspace; null goes back to the built-in default design. Omit to leave it unchanged.

Output Schema

TableJSON Schema

Name	Required	Description	Default
`id`	Yes
`title`	Yes
`status`	Yes
`screens`	Yes
`themeId`	Yes
`createdAt`	Yes
`direction`	Yes
`updatedAt`	Yes
`navigation`	Yes
`sourceKind`	Yes
`contentHash`	Yes
`customFonts`	Yes
`workspaceId`	Yes
`passingScore`	Yes
`quizFeedback`	Yes
`certificateId`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

First observedSep 26, 2026

TDQS

A4/5.0

Behavior3/5

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

Annotations already declare readOnlyHint=false and destructiveHint=true, so the write/destructive nature is covered. The description adds partial-update semantics but does not disclose behavioral details such as screens being replaced wholesale rather than merged; that detail lives in the schema, not the description.

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?

Two short sentences with no filler; the core partial-update rule is front-loaded and the optionality guidance is immediately actionable.

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 complex tool with a very detailed schema and an output schema, the description covers the essential update semantics and id requirement. It does not need to repeat schema details, though a brief pointer to update_screen for single-screen changes would make it slightly more complete.

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 the schema already documents each parameter's omit-to-leave-unchanged behavior. The description's 'send only what changes' is a useful summary but adds no per-parameter meaning beyond the schema.

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 states a specific verb ('partially updates'), resource ('a course'), and identifier ('by id'), and clarifies the partial-update contract. This distinguishes it from create_course, delete_course, and update_screen without needing to open the schema.

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?

It gives clear usage context: every field except id is optional and callers should send only what changes. It does not explicitly name alternatives or exclusions in the description, though the screens parameter schema points to update_screen for single-screen edits.

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

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

Resources

Need Help?