Skip to main content
Glama

Create a model

create_model

Create a new model in this workspace. It is open to assistants from the start. Returns a one-time AMT link where the user uploads the training file (the file never passes through the chat).

Input Schema

NameRequiredDescriptionDefault
nameYes
readsNotext
descriptionNoWhat it should predict, in plain words.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

B3.3/5.0
Behavior4/5

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

Annotations cover the safety profile (readOnlyHint=false, destructiveHint=false, openWorldHint=false), and the description adds genuinely useful context beyond them: the model is 'open to assistants from the start' and creation returns a one-time AMT link for the training file that never passes through chat. The one-time nature of the link is important behavioral detail the agent would otherwise not know.

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?

Three short sentences, purpose front-loaded, and each sentence carries distinct information (what is created, initial sharing state, return artifact plus a security note). No filler.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

There is no output schema, so describing the returned one-time AMT link is valuable and present. However, for a mutation tool with three parameters at 33% schema coverage, the description omits any parameter explanation, leaving the reads enum and name constraints undocumented anywhere the agent will see them.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is only 33% – only the 'description' parameter is documented, while 'name' and the 'reads' enum (text/pictures) are bare. The description compensates for none of this, mentioning no parameter names, formats, or the meaning of the reads choice.

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?

States a specific verb and resource: 'Create a new model in this workspace.' The agent can distinguish this from list_models (read) or train (train an existing model) without opening a schema, though the description never explicitly names those siblings or states the boundary.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description says what happens on creation but never when to choose this tool over alternatives like train, list_models, or model_report. There is no prerequisite, ordering, or exclusion guidance for the agent to act on.

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.

Resources