Skip to main content
Glama

Anima MCP Server

by io.github.AnimaApp
OverviewDiscussionsAdmin

List Workspace Artifacts

workspace-list_artifacts
Read-only

List the artifacts you can read, most recently updated first — across every workspace you can access, or in one with workspaceId. Each row's sessionId is what artifact-explore, artifact-edit and artifact-get_git_token take.

Returns: { success: true, artifacts: [{ name, type: app | knowledge | markdown | asset, sessionId, workspaceId, workspaceName, updatedAt }], truncated, nextSteps }. Rows cover only what you can access, and the listing is capped (truncated: true means more exist): report what you found, never a total, and never say the team has no artifacts.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
workspaceIdNoOptional. List only this workspace — an id from workspace-list_workspaces. Omit to list every workspace you can access.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • addedInput schema / properties / workspaceId
      Added value: +{
+  "description": "Optional. List only this workspace — an id from workspace-list_workspaces. Omit to list every workspace you can access.",
+  "type": "string"
+}
  2. Added

TDQS

A4.5/5.0
Behavior4/5

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the description's read-only claim aligns. It adds value by disclosing truncation behavior (truncated: true means more exist) and instructing to never report a total or claim no artifacts exist, which are important behavioral nuances beyond the annotations.

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?

Two sentences plus a return block, all essential. The core action and scope are front-loaded, and the return structure is clearly delineated. No wasted words.

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 1-param, optional list tool, the description covers scope, return format, truncation semantics, and reporting guidance. It fully equips an agent to call it correctly without an output schema.

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% with a clear description of workspaceId. The description reinforces that it's optional and specifies the source of the id (from workspace-list_workspaces), adding meaningful context beyond the schema alone.

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 (list), resource (artifacts), and scope (accessible ones, optionally filtered by workspaceId). It also distinguishes from siblings by noting sessionId is used by artifact-explore, artifact-edit, and artifact-get_git_token, clarifying this is the listing tool.

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?

Clearly explains when to use it (to list artifacts across all accessible workspaces or a single one) and how to scope with workspaceId, even pointing to workspace-list_workspaces for the id. It does not explicitly contrast with alternatives, but the purpose is unambiguous given the sibling set.

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