Skip to main content
Glama

Anima MCP Server

by io.github.AnimaApp
OverviewDiscussionsAdmin

Create Knowledge Artifact

artifact-create_knowledge

Create a NEW knowledge artifact from Anima's knowledge-base template. Returns a ready artifact; never edits an existing one.

Call with no arguments, or with an optional name (defaults to "Untitled project") and workspaceId. No files, ZIP upload, framework, or artifact type are accepted. The template supplies the initial files and determines the framework.

Returns the sessionId, initial revision, artifactUrl, name, framework, fileCount, skippedFiles, and applicable preview URLs and Git access. Share artifactUrl with the human. Use artifact-explore and artifact-edit to inspect and change its contents. Only use artifact-publish when the user explicitly asks for a public deployment.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
nameNoOptional display name; defaults to "Untitled project".
workspaceIdNoWhere to create it — an id from workspace-list_workspaces. Optional when you can create in only one workspace; otherwise required, since there is no default workspace.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • addedInput schema / properties / workspaceId
      Added value: +{
+  "description": "Where to create it — an id from workspace-list_workspaces. Optional when you can create in only one workspace; otherwise required, since there is no default workspace.",
+  "type": "string"
+}
  2. Added

TDQS

A4.7/5.0
Behavior5/5

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

Annotations already indicate a non-read-only, open-world, non-idempotent, non-destructive operation. The description adds substantial context: it never edits existing artifacts, returns a ready artifact, lists the exact return fields, and instructs sharing the artifactUrl with the human. This goes well beyond the annotations and sets clear expectations.

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?

The description is compact yet information-dense: purpose is front-loaded, followed by call constraints, return values, and sibling routing. Every sentence earns its place, and nothing is redundant with the schema or annotations.

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?

For a create tool with two optional parameters and no output schema, the description covers the purpose, invocation, parameter constraints, return structure, and recommended next steps (explore, edit, publish). An agent can call it correctly and know what to do with the result without any further lookups.

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 coverage is 100%, so the schema fully documents both 'name' and 'workspaceId' with defaults and source guidance. The description reiterates defaults and adds a useful constraint ('No files, ZIP upload, framework, or artifact type are accepted'), but overall it adds only marginal value beyond the schema. Baseline 3 is appropriate.

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?

The description states a specific verb and resource ('Create a NEW knowledge artifact from Anima's knowledge-base template') and explicitly distinguishes it from editing ('never edits an existing one') and from other creation modes ('No files, ZIP upload, framework, or artifact type are accepted'). This differentiates it clearly from artifact-create, artifact-edit, and other siblings.

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

Usage Guidelines5/5

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

It specifies how to call the tool ('Call with no arguments, or with an optional name... and workspaceId'), states what is not accepted, and routes the agent to sibling tools for subsequent actions ('Use artifact-explore and artifact-edit to inspect and change its contents. Only use artifact-publish when the user explicitly asks for a public deployment'). The 'never edits an existing one' line implicitly warns against using it for edits, giving a when-not.

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

All Anima MCP Server 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