Skip to main content
Glama

hjarni

by com.hjarni
OverviewDiscussionsAdmin

containers-create

Create a new container (folder) for organizing notes. Required: name (string). Optional: emoji (one emoji shown as the folder's icon in place of the folder glyph, e.g. 📦), description (string), negative_space (string — what does NOT belong in this folder, so notes can be routed away from it), parent_id (integer or null) for nesting inside another container — null or omitted creates it at the top level (so does the space's root id: the root is not a folder, and the response then reports parent_id null), team_id (integer) to create the container in a team instead of personal space. When team_id is set, parent_id (if provided) must belong to the same team. After creating, consider setting up LLM instructions with instructions-update.

Input Schema

NameRequiredDescriptionDefault
nameYesContainer name (required)
emojiNoOne emoji shown as the folder's icon, e.g. "📦". Omit it for the plain folder icon.
team_idNoCreate container in this team instead of personal space. Omit it (or send null) for personal space.
parent_idNoParent container ID for nesting, or null/omitted for a top-level container. Must belong to the same scope (personal or team) as the new container.
descriptionNoContainer description
negative_spaceNoWhat does NOT belong in this folder (e.g. 'No meeting notes, those go in Meetings'). Helps route notes away from the wrong place.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • addedInput schema / properties / emoji
      Added value: +{
+  "description": "One emoji shown as the folder's icon, e.g. \"📦\". Omit it for the plain folder icon.",
+  "type": [
+    "string",
+    "null"
+  ]
+}
  2. Changed2 schema fields changed
    • changedInput schema / properties / team_id / description
      Previous value: -"Create container in this team instead of personal space"New value: +"Create container in this team instead of personal space. Omit it (or send null) for personal space."
    • changedInput schema / properties / team_id / type
      Previous value: -"integer"New value: +[
+  "integer",
+  "null"
+]
  3. Changed2 schema fields changed
    • changedInput schema / properties / parent_id / description
      Previous value: -"Parent container ID for nesting. Must belong to the same scope (personal or team) as the new container."New value: +"Parent container ID for nesting, or null/omitted for a top-level container. Must belong to the same scope (personal or team) as the new container."
    • changedInput schema / properties / parent_id / type
      Previous value: -"integer"New value: +[
+  "integer",
+  "null"
+]
  4. Changed1 schema field changed
    • addedInput schema / properties / negative_space
      Added value: +{
+  "description": "What does NOT belong in this folder (e.g. 'No meeting notes, those go in Meetings'). Helps route notes away from the wrong place.",
+  "type": [
+    "string",
+    "null"
+  ]
+}
  5. Changed2 schema fields changed
    • changedInput schema / properties / parent_id / description
      Previous value: -"Parent container ID for nesting"New value: +"Parent container ID for nesting. Must belong to the same scope (personal or team) as the new container."
    • addedInput schema / properties / team_id
      Added value: +{
+  "description": "Create container in this team instead of personal space",
+  "type": "integer"
+}
  6. Changed1 schema field changed
    • changedInput schema / properties / name / description
      Previous value: -"Container name"New value: +"Container name (required)"
  7. First observed

TDQS

A4/5.0
Behavior4/5

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

Annotations already declare non-readOnly, non-destructive, non-idempotent, so the bar is lower. The description adds real behavioral nuance: parent_id=null creates a top-level container, the space's root id is treated as top-level and the response then reports parent_id null, and team_id forces parent_id to be in the same team. It doesn't cover duplicate-name behavior or error cases.

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

Conciseness4/5

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

Front-loaded with the action, then a single dense sentence enumerating required vs optional parameters with their semantics. Every clause carries information; only slight redundancy with the schema's type declarations keeps it from a 5.

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?

Covers all six parameters, scope behavior, nesting rules, and a sensible next action, and notes what the response reports for parent_id. No output schema exists but is not needed. Duplicate-name/error behavior is the only notable gap.

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?

Schema coverage is 100% so baseline is 3, but the description genuinely adds meaning beyond the schema: negative_space is explained as 'what does NOT belong in this folder, so notes can be routed away from it', and the root-id/parent_id nuance and team constraint are not in the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

Specific verb+resource: 'Create a new container (folder) for organizing notes.' An agent can distinguish this from containers-update/delete/list. It stops short of explicitly naming a sibling to contrast with, which keeps it at 4 rather than 5.

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?

Clear context for when to use and a explicit follow-up cross-reference: 'After creating, consider setting up LLM instructions with instructions-update.' No 'when not to use' or alternative-routing guidance for overlapping tools.

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

All hjarni toolsInspect
Try in Browser
Context All Your Agents Can ShareAgents share what they learn, hand off work, and hold it when you switch models. Start with 5 GB free.fulcradynamics.comAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources