Skip to main content
Glama
Mipiti

Mipiti MCP Server

by Mipiti
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Hybrid

Create Group

create_group

Creates a tag to group models for viewing and reporting, without asserting relationships or moving credit. Optionally adds initial members.

Instructions

Create a tag, optionally with its first members. Mutating.

A tag groups models for viewing and reporting without asserting any relationship between them and without moving credit. Names are unique within the workspace (409 on a clash). Every model named in model_ids must be one the caller can access in this workspace.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
nameYesthe tag name (unique within the workspace).
model_idsNooptional initial member model ids.
descriptionNooptional description.
server_versionYes

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed4 schema fields changedv0.85.0
    • removedInput schema / properties / kind
      Removed value: -{
-  "description": "``\"tag\"`` or ``\"system\"``.",
-  "type": "string"
-}
    • changedInput schema / properties / model_ids / description
      Previous value: -"optional initial member model ids — ``\"tag\"`` only."New value: +"optional initial member model ids."
    • changedInput schema / properties / name / description
      Previous value: -"the group name (unique within the workspace for its kind)."New value: +"the tag name (unique within the workspace)."
    • changedInput schema / required
      Previous value: -[
-  "server_version",
-  "kind",
-  "name"
-]New value: +[
+  "server_version",
+  "name"
+]
  2. Addedv0.68.2

TDQS

A4.6/5.0
Behavior5/5

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

No annotations are provided, yet the description carries the full burden well: declares 'Mutating', warns uniqueness is per-workspace with 409 on a clash, and adds an access precondition ('every model named in model_ids must be one the caller can access'). That is rich behavioral detail beyond what the schema encodes.

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?

Front-loaded with the action and the core distinguishing property, then the necessary operational facts (uniqueness, 409, access check). Every sentence earns its place; no padding.

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 4-param mutating tool with no annotations, the description covers mutation semantics, uniqueness/conflict behavior, and preconditions, and an output schema exists so return values need not be explained. It omits any mention of the server_version parameter or required-permission specifics, leaving a small 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 75% and already documents name/model_ids/description. The description reinforces semantics — uniqueness scope for name and the access precondition for model_ids — adding value the schema does not convey, though it says nothing about model_ids being nullable or server_version.

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?

States a specific verb (Create) and resource (a tag/group) and immediately disambiguates the concept: 'A tag groups models for viewing and reporting without asserting any relationship.' This distinguishes create_group from relationship-asserting siblings like attach_foundation or add_model_to_group.

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?

Clarifies intent — grouping for viewing/reporting, not relationship assertion — which implicitly tells an agent when this is the right tool versus modeling relationships. It does not explicitly name an alternative or when-not-to-use sibling, so it falls short of a 5.

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

Deploy Server

Other Tools