Skip to main content
Glama

Kinetune

by com.kinetune
OverviewDiscussionsAdmin

Create an organization

create_organization

A new organization owned by you, with its own music, videos, Looks and credits. Creates an empty organization (a workspace, in the app) with the signed-in person as its owner; with an API key, the member who created the key (the key needs organizations:write). type artist is for one artist (add that artist next with create_artist; its songs then need no artist_id), label for a roster. It starts with no plan and no credits: the owner chooses a plan in the app before anything can be created in it. These credentials keep acting for their current organization: to work in the new one, sign in again and pick it, or create an API key in it.

Input Schema

NameRequiredDescriptionDefault
nameYesThe workspace name, as people see it in the app (an artist workspace usually carries the artist name)
typeYesartist: one artist and its songs; label: a roster of artists

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed3 schema fields changed
    • changedInput schema / properties / name / description
      Previous value: -"The organization name, as people see it in the app"New value: +"The workspace name, as people see it in the app (an artist workspace usually carries the artist name)"
    • addedInput schema / properties / type
      Added value: +{
+  "description": "artist: one artist and its songs; label: a roster of artists",
+  "enum": [
+    "artist",
+    "label"
+  ],
+  "type": "string"
+}
    • changedInput schema / required
      Previous value: -[
-  "name"
-]New value: +[
+  "name",
+  "type"
+]
  2. Added

TDQS

A4.6/5.0
Behavior5/5

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

Goes well beyond the annotations: discloses the authorization requirement ('the key needs organizations:write'), that the owner is the signed-in person or key creator, that the org starts with no plan and no credits so nothing can be created until a plan is chosen, and that existing credentials keep acting on the old org. These are exactly the operational facts an agent would otherwise get wrong.

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 core action and dense with useful facts, but the opening two clauses overlap ('A new organization owned by you, with its own music, videos, Looks and credits' followed by 'Creates an empty organization'), and the mid-sentence interjections ('a workspace, in the app') interrupt the flow.

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?

With only two required parameters, no output schema and full schema coverage, the description closes the remaining gaps: resulting state (empty, no plan, no credits), auth requirement, ownership, and how to continue working in the new org. An agent needs nothing else to call this correctly.

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 the baseline is 3, but the description adds real downstream meaning for the enum: 'artist' implies a subsequent create_artist call and artist_id-free songs, 'label' implies a roster. The 'name' parameter is only echoed from the schema, not extended.

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 and resource ('Creates an empty organization (a workspace, in the app)') and immediately scopes what it is: its own music, videos, Looks and credits, owned by the caller. It also disambiguates from siblings by defining the two mutually exclusive shapes against create_artist ('type artist is for one artist... label for a roster').

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?

Explicit guidance on which type to pick and what to do next ('add that artist next with create_artist; its songs then need no artist_id'), plus a clear post-creation credential instruction. It stops short of naming the full alternative set (update_organization, list_organizations) or stating when not to create a new org at all.

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

All Kinetune toolsInspect
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