srgplus-mcp

Official

Overview Schema Source Related Servers Discussions Admin

add_subcontent

Link existing content items as subcontent within a collection section to build nested structures like lessons in a course. Specify parent content, section, and subcontent IDs to organize content hierarchically.

Instructions

Link existing content items as subcontent inside a collection section.

Subcontent is the nested content that lives inside a Collection — think
lessons inside a course, or chapters inside a module.  A Content item
automatically becomes a Collection once it has at least one subcontent item.

workspace_id: target workspace ID — get available IDs from list_workspaces()
content_id:     ID of the collection (the parent content item)
category_name:  "Content" for nested content items, "Asset" for nested assets
section_id:     ID of the section to add the subcontent into
                (create a section first with create_content_section if needed)
subcontent_ids: list of content IDs to link as subcontent (one or more)

Input Schema

TableJSON Schema

Name	Required	Description	Default
`content_id`	Yes
`section_id`	Yes
`workspace_id`	Yes
`category_name`	Yes
`subcontent_ids`	Yes

Output Schema

TableJSON Schema

Name	Required	Description	Default
`result`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.4.18Sep 8, 2026

TDQS

A4.5/5.0

Behavior4/5

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

Annotations indicate readOnlyHint=false and destructiveHint=false, which the description does not contradict. The description transparently explains the side effect: a Content item automatically becomes a Collection once it has at least one subcontent item. It does not mention permission requirements or whether existing subcontent is replaced, but the annotations carry the basic safety profile and the description adds meaningful behavioral context.

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 well-structured with a short summary followed by a clear bullet-style parameter list. Each line is purposeful and directly aids invocation. No fluff or redundancy is present.

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?

The description covers the operation, parameter meanings, and key behavioral rule (automatic Collection promotion). It does not mention the output schema contents, but the output schema is present and self-explanatory. Given the tool's moderate complexity, the description is complete enough for correct usage without being overlong.

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?

Although the JSON schema provides no descriptions, the tool description manually explains every parameter: workspace_id, content_id, category_name, section_id, and subcontent_ids. It even clarifies the allowed values for category_name ('Content' vs 'Asset') and tells users where to find workspace IDs. This fully compensates for the schema's lack of descriptions.

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 clearly states the tool's action: linking existing content items as subcontent inside a collection section. It elaborates with a concrete analogy ('lessons inside a course, chapters inside a module') and clarifies the automatic Collection promotion rule, making the purpose specific and distinguishable from sibling tools like add_content_to_category or move_subcontent.

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 explains when to use the tool by defining subcontent and when an item becomes a Collection. It also provides helper pointers for obtaining workspace IDs and creating sections via sibling tools. It does not explicitly say when NOT to use this tool versus alternatives like move_subcontent, but the context and parameter guidance are sufficient for most cases.

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

Deploy Server