Ankra

Create AI model

create_ai_model

Add a model to the organisation's AI model catalog (the twin of ankra ai models create): the catalog the chat model picker and the AI lanes choose from. key, display_name and model_id are required; endpoint_id names the organisation's own OpenAI-compatible endpoint that serves it. Needs ai.manage (organisation owners and admins). Never takes or returns a provider key.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "key": "<key>",
      "display_name": "<display_name>",
      "model_id": "<model_id>"
    },
    "name": "create_ai_model"
  }
}

Input Schema

Name	Required	Description
`key`	Yes	The catalog key: lowercase letters, digits and hyphens, unique in the organisation's catalog.
`tier`	No	The tier the model fills (quick, standard or deep); empty for none.
`model_id`	Yes	The provider's model id, e.g. claude-opus-5, or the model a custom endpoint serves.
`is_enabled`	No	Whether the picker offers the model; default true.
`sort_order`	No	Position in the picker; lower first.
`description`	No	A short description shown beside the name.
`endpoint_id`	No	The id of the organisation's OpenAI-compatible endpoint that serves the model (list_ai_endpoints names them); omit or null for an Ankra-managed model.
`display_name`	Yes	The name the chat model picker shows.
`supports_tools`	No	Whether the model can call tools; default true.
`supports_images`	No	Whether the model reads images; default false.
`max_output_tokens`	No	The most tokens one answer may carry; 0 for the default.
`supports_thinking`	No	Whether the model supports extended thinking; default false.
`context_window_tokens`	No	The model's context window in tokens; 0 for the default.

Schema Changelog

Changes observed during successful MCP inspections.

AddedNov 8, 2026

TDQS

A3.7/5.0

Behavior4/5

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

Annotations already declare a non-read-only, non-idempotent, non-destructive write. The description adds genuinely useful context beyond them: the required permission level, the downstream effect (the model appears in the picker and AI lanes), and the security constraint that it never takes or returns a provider key.

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?

Two dense sentences with the action and required fields front-loaded, then permissions and the key-safety note. No filler, though the parenthetical CLI twin reference is marginal value for an agent.

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 13-parameter creation tool with no output schema, the description covers purpose, prerequisites, the endpoint distinction, and the key-handling guarantee. It does not say what is returned on success, but that is a minor gap given the scope.

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

Parameters3/5

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

Schema description coverage is 100%, so every field including endpoint_id and tier is already documented. The description's parameter content (required key/display_name/model_id, endpoint_id semantics) largely restates the schema; baseline 3 applies.

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 ('Add a model to the organisation's AI model catalog') and explains what the catalog is for (the chat model picker and AI lanes). It does not explicitly name the sibling it differs from (update_ai_model, delete_ai_model), but the create verb is unambiguous.

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

Usage Guidelines3/5

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

Prerequisites are clear ('Needs ai.manage (organisation owners and admins)'), and the endpoint_id note tells the agent when to point at a custom endpoint versus an Ankra-managed model. However, there is no explicit when-to-use-this-versus-update_ai_model guidance, so the routing is only implied.

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

All Ankra tools Inspect

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.