Skip to main content
Glama
Ivy-Innovation

CubeLife

by Ivy-Innovation
OverviewSchemaRelated ServersScoreDiscussions
TypeScript
Remote

Characters live in a pixel-art room, perform activities based on agent state, show emotions, and have creature companions. View them at life.cubeworld.co.za, on the desktop companion, or embedded in your own app via <iframe>.

Packages

This repo contains three packages:

Package

Install

Description

@cubelife/sdk

npm install @cubelife/sdk

Node.js SDK for state reporting

cubelife

npm install -g cubelife

CLI + MCP server for AI coding tools

cubelife

pip install cubelife

Python SDK for state reporting

Related MCP server: The Agents MCP Server

Quick start

MCP server (for Claude Code, Cursor, Copilot, Windsurf, Cline, Codex)

npx cubelife tutorial           # create account + agent
npx cubelife setup claude-code  # auto-configure MCP

Your agent gets four tools: cubelife_report, cubelife_complete, cubelife_error, cubelife_status.

Node SDK

npm install @cubelife/sdk
import { CubeLifeClient } from '@cubelife/sdk';

const client = new CubeLifeClient({ apiKey: process.env.CUBELIFE_API_KEY });
await client.report('coding', { detail: 'Building the login page', progress: 0.5 });
await client.report('complete', { detail: 'Login page shipped' });

Python SDK

pip install cubelife
from cubelife import CubeLifeClient

client = CubeLifeClient("your-agent-key")
client.report("coding", detail="Building the login page", progress=0.5)
client.report("complete", detail="Login page shipped")

Creature companions

Every agent gets a creature companion (fox, owl, cat, dragon, wolf, phoenix, or slime) that reacts alongside the character.

MCP server

The CLI includes an MCP server for AI coding tools. Auto-configure for your tool:

npx cubelife setup claude-code    # Claude Code
npx cubelife setup cursor         # Cursor
npx cubelife setup windsurf       # Windsurf
npx cubelife setup copilot        # GitHub Copilot
npx cubelife setup cline          # Cline
npx cubelife setup codex          # Codex

Or manually: claude mcp add cubelife -- npx cubelife mcp

Links

Licence

MIT (source code). Pixel art sprite assets are proprietary (see SPRITE-LICENSE).

Available Tools

4 tools
cubelife_completeA

Mark the current task as complete. Triggers a celebration animation on the character.

ParametersJSON Schema
NameRequiredDescriptionDefault
detailNoWhat was completed

TDQS

A3.6/5.0
Behavior3/5

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

No annotations provided, so description carries full burden. It discloses the celebration animation side effect, but does not mention persistency, reversibility, or authentication needs.

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, front-loaded with essential information, no filler.

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 simple tool with one optional parameter and no output schema, the description covers purpose and side effect adequately. Could mention if it requires a current task context.

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% and the parameter 'detail' is described in the schema. The description adds no additional meaning beyond 'What was completed'.

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 clearly states the tool marks a task as complete and triggers a celebration animation, which distinguishes it from siblings like cubelife_error and cubelife_report.

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?

No guidance on when to use this tool versus alternatives, nor any exclusion criteria or prerequisites.

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

cubelife_errorB

Report that an error occurred. Shows frustration on the character.

ParametersJSON Schema
NameRequiredDescriptionDefault
detailNoWhat went wrong

TDQS

B3.4/5.0
Behavior3/5

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

No annotations provided, so the description carries full burden. It adds behavioral context ('Shows frustration on the character') but does not detail other effects like logging or return behavior.

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 concise sentences, front-loaded with purpose and behavioral effect. No fluff or redundancy—each sentence adds value.

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 simple tool with one optional parameter and no output schema, the description is adequate. It explains the action and visual outcome, though mentioning potential side effects (e.g., logging) would improve completeness.

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% with one parameter 'detail' described as 'What went wrong'. The description does not enhance this beyond the schema, so baseline 3 is appropriate.

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?

The description clearly states the tool reports an error and shows frustration, which is specific to the cubelife context. However, it does not differentiate from sibling tools like cubelife_report, relying on the tool name for distinction.

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?

No guidance on when to use this tool versus alternatives (e.g., cubelife_report) or when not to use it. The description lacks contextual usage advice.

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

cubelife_reportA

Report the AI agent's current work state to CubeLife. Call this when starting a new task or changing activity.

ParametersJSON Schema
NameRequiredDescriptionDefault
stateYesThe current work state
detailNoBrief description of what the agent is doing
progressNoTask progress from 0 to 1
sentimentNoCurrent sentiment

TDQS

A3.9/5.0
Behavior3/5

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

No annotations provided; description only says 'report state'. It doesn't disclose side effects, idempotency, or what happens after reporting (e.g., logging, overwriting previous state). Minimal but not misleading.

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, front-loaded with purpose and usage. No fluff; every word adds value.

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?

No output schema; description doesn't explain expected return or confirmation. Sibling tools exist, but for a report tool, it's minimally adequate.

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 description doesn't need to add much. It implicitly ties state to 'current work' but adds no new meaning beyond the schema's parameter descriptions.

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 clearly states the tool reports current work state to CubeLife. It specifies when to use it ('when starting a new task or changing activity'), which distinguishes it from siblings like cubelife_complete or cubelife_error.

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?

Explicitly states when to call ('starting a new task or changing activity'). While it doesn't say when not to use, the guidance is clear and sufficient for an agent to decide.

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

cubelife_statusA

Get the agent's current state.

ParametersJSON Schema
NameRequiredDescriptionDefault

No parameters

TDQS

A4.1/5.0
Behavior3/5

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

No annotations provided, so description must disclose behavioral traits. It implies a read-only operation with 'Get', but does not explicitly state safety or side effects. For a simple status check, this is adequate but minimal.

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?

Single sentence, no extra words, efficiently conveys the tool's purpose. Every word earns its place.

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?

Given zero parameters, no output schema, and low complexity, the description is fully adequate for an agent to understand how to use this tool.

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?

No parameters exist, and schema coverage is 100%. Baseline for 0 parameters is 4, and description adds no parameter information, which is acceptable given no parameters.

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?

Description clearly states 'Get the agent's current state' with specific verb and resource. Differentiates from sibling tools (complete, error, report) which imply different actions.

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?

No explicit guidance on when to use this tool vs siblings. Context implies it's for querying status, but no exclusions or alternatives are mentioned.

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

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.

  1. 4 tool updatesv1.0.0
    • First observedcubelife_complete
    • First observedcubelife_error
    • First observedcubelife_report
    • First observedcubelife_status
Install Server
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A3.9/5.0
Disambiguation5/5

Each tool has a distinct purpose: marking completion, reporting errors, updating work state, and retrieving status. No overlap in functionality.

Naming Consistency4/5

All tools follow the 'cubelife_verb' pattern with underscore, though 'error' and 'status' are nouns used as verbs, causing slight inconsistency.

Tool Count5/5

Four tools are appropriate for managing an agent's lifecycle and state reporting, covering key actions without being excessive or insufficient.

Completeness4/5

The surface covers starting/changing tasks, completion, error reporting, and status queries. Missing a cancel or pause operation, but core functionality is present.

Maintenance

ActivityInactive
ResponsivenessSyncing

Resources

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

Related MCP Servers

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/Ivy-Innovation/cubelife'

If you have feedback or need assistance with the MCP directory API, please join our Discord server