Skip to main content
Glama

update_storyline

Update part of a storyline draft — fields you don't pass stay as they are (GET-then-merge on top of a full PUT underneath).

concurrency: "user" = progress belongs to the person (shared across sessions); "session" =
progress belongs to the case (one run per session). Changes affect only **future** enrolments;
in-flight runs are not migrated.

⚠️ Especially `graph`: not passing it = keep the existing graph. (This tool once treated "no
graph" as replace-with-empty — renaming a storyline wiped its whole flow. Semantics are now
partial; to truly clear the graph, pass `{"nodes":[],"edges":[]}` explicitly.)
graph/Node/Exit/RuleAst structures: see create_storyline. Pass expected_version for optimistic
locking. Read the response to verify, then validate_storyline.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
keyYes
nameNo
entryNo
graphNo
agent_nameYes
allow_exitNo
is_defaultNo
concurrencyNo
descriptionNo
on_completeNo
display_nameNo
show_profileNo
storyline_idYes
enroll_triggerNo
profile_schemaNo
user_visibilityNo
expected_versionNo
next_storyline_idNo
allow_agent_enrollNo
learner_visibilityNo

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
resultYes

TDQS

A4.7/5.0
Behavior5/5

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

With no annotations, the description carries the full burden and excels. It discloses the GET-then-merge PUT mechanism, concurrency semantics, future-enrollment-only impact, a historical bug affecting graph replacement, explicit clearing instructions, optimistic locking via expected_version, and a post-update verification/validation step. This is exemplary transparency for a mutating tool.

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 multi-paragraph but every sentence earns its place. It front-loads the core partial-update concept, then systematically covers concurrency, the graph pitfall, validation, and locking. The formatting with bold and the warning emoji improves scannability without padding.

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 high complexity (20 params, partial semantics, concurrency, optimistic locking, destructive potential), the description covers all critical aspects: what partial means, how concurrency affects future runs, how to clear the graph safely, how to handle version conflicts, and what to do after updating. It also leverages create_storyline as a reference and mentions validate_storyline for verification.

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?

The schema has 20 parameters with 0% description coverage, but the description adds critical semantics for concurrency (enumerating 'user' vs 'session' behavior), graph (partial semantics and how to clear), and expected_version (optimistic locking). It also points to create_storyline for complex structures. Most other parameters are self-explanatory from names, but not all are individually explained, so 4 is appropriate.

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 **part** of a storyline draft' which clearly identifies the verb ('update'), resource ('storyline draft'), and the crucial partial-update scope. It distinguishes itself from siblings like create_storyline by emphasizing that unspecified fields are preserved, making the tool's unique role unambiguous.

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?

The description gives excellent context on when to use this tool: for partial updates where omitted fields are retained. It also provides explicit guidance for clearing the graph (pass empty arrays) and points to create_storyline for structure details. However, it does not explicitly contrast with create_storyline or clone_storyline, so it falls short of a perfect 5.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A3.6/5.0
Disambiguation4/5

Tools are mostly distinct by domain and action. A few pairs like add_knowledge_file vs add_knowledge_text or build_knowledge_index vs patch_knowledge_index could cause confusion, but descriptions clearly differentiate them.

Naming Consistency4/5

The vast majority follow a consistent verb_noun snake_case pattern (create_*, list_*, get_*, update_*). A few outliers like tenant_info, usage_stats, and page_context_stats are noun-first, deviating slightly from the otherwise uniform scheme.

Tool Count1/5

With 50 tools, this is a very large surface that exceeds typical well-scoped server sizes. Even for a broad platform management API, the sheer number makes it heavy and potentially overwhelming, matching the '50+' extreme mismatch category.

Completeness2/5

The server covers creation, reading, updating, and listing for most resources but lacks any delete operations (no delete_agent, delete_knowledge_base, delete_skill, delete_share, delete_storyline, delete_page_context). This is a significant gap in lifecycle coverage that will force agents to work around missing functionality.

Resources