Skip to main content
Glama
aic0t

AI Coach MCP Server

by aic0t
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

Report your activity to the mascot

report_ai_coach_activity
Idempotent

Update the AI Coach mascot with your current activity state to trigger animations and speech bubbles for thinking, working, waiting, succeeded, or failed.

Instructions

Let the AI Coach mascot act out what you are doing, with its own animation and speech bubble. Call with 'thinking' or 'working' when starting a task (optionally with a short label), 'waiting' when you need the user, 'succeeded' or 'failed' when you finish. Repeats of the same state are not re-announced, so calling on every step is safe.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
labelNoWhat you are doing, up to 60 characters.
stateYesYour own current activity. thinking / working / waiting are ongoing; succeeded / failed are terminal; idle removes the display.
localeNoDisplay language (BCP 47).
mascotIdNoA mascotId returned by status. Defaults to the primary mascot when omitted.
ttlSecondsNoSeconds to keep this state (default 120, max 900).

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed5 schema fields changedv0.1.4
    • changedInput schema / properties / label / description
      Previous value: -"Short description of what you are doing (up to 60 characters). Shown on the second line of the bubble."New value: +"What you are doing, up to 60 characters."
    • changedInput schema / properties / locale / description
      Previous value: -"Display language hint (BCP 47). The dashboard view passes hostContext.locale through unchanged."New value: +"Display language (BCP 47)."
    • changedInput schema / properties / state / description
      Previous value: -"Your own current activity. thinking / working / waiting are ongoing; succeeded / failed are terminal and clear themselves; idle removes the display."New value: +"Your own current activity. thinking / working / waiting are ongoing; succeeded / failed are terminal; idle removes the display."
    • changedInput schema / properties / ttlSeconds / description
      Previous value: -"How long to keep this state, in seconds (default 120, max 900). The mascot quietly returns to normal once it expires."New value: +"Seconds to keep this state (default 120, max 900)."
    • changedOutput schema / (root)
      Previous value: -{
-  "additionalProperties": false,
-  "properties": {
-    "announced": {
-      "type": "boolean"
-    },
-    "connection": {
-      "enum": [
-        "connected",
-        "app_unavailable",
-        "incompatible"
-      ],
-      "type": "string"
-    },
-    "error": {
-      "additionalProperties": false,
-      "properties": {
-        "code": {
-          "type": "string"
-        },
-        "reason": {
-          "type": "string"
-        },
-        "retryable": {
-          "type": "boolean"
-        }
-      },
-      "required": [
-        "code",
-        "retryable"
-      ],
-      "type": "object"
-    },
-    "expiresAt": {
-      "type": "string"
-    },
-    "mascotId": {
-      "type": "string"
-    },
-    "protocolVersion": {
-      "const": 1,
-      "type": "number"
-    },
-    "shown": {
-      "type": "boolean"
-    },
-    "state": {
-      "enum": [
-        "thinking",
-        "working",
-        "waiting",
-        "succeeded",
-        "failed",
-        "idle"
-      ],
-      "type": "string"
-    },
-    "updatedAt": {
-      "type": "string"
-    }
-  },
-  "required": [
-    "protocolVersion",
-    "connection",
-    "state",
-    "announced",
-    "shown",
-    "updatedAt"
-  ],
-  "type": "object"
-}New value: +null
  2. First observedv0.1.2

TDQS

A4.7/5.0
Behavior5/5

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

Beyond the idempotentHint annotation, the description adds valuable behavioral detail: repeats of the same state are not re-announced, making frequent calls safe. It also clarifies that 'succeeded' and 'failed' are terminal and 'idle' removes the display, which is more context than the annotation alone provides. No contradiction with 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?

The description is two sentences with no filler. It front-loads the main purpose, then immediately provides the state usage patterns and the important deduplication behavior. Every sentence earns its place and directly helps the agent decide when and how to invoke the tool.

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?

The description covers the essential behavioral contract: what the tool does, when to call it, how states map to scenarios, and why repeated calls are safe. The remaining parameters (locale, mascotId, ttlSeconds) are fully documented in the input schema, and no output schema is provided, so the description is complete for an agent to use the tool correctly.

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%, so the baseline is 3. The description goes beyond the schema by attaching real-world usage semantics to the state values: which states map to task start, user interaction, and completion. It also notes that the label is optional and short, adding practical context not fully captured by the schema.

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's purpose: having the AI Coach mascot act out the agent's current activity with animation and a speech bubble. It uses a specific verb ('report') and resource ('activity to the mascot'), making it distinct from sibling tools like show_ai_coach_message or open_ai_coach_dashboard.

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?

The description gives explicit guidance on when to call the tool: use 'thinking' or 'working' when starting a task, 'waiting' when needing the user, and 'succeeded' or 'failed' when finishing. It does not explicitly mention when not to use it or name alternative tools, but the call patterns are clearly actionable.

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

Deploy Server

Other Tools