Skip to main content
Glama
starecz

karea-mcp

by starecz
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

karea_quick_task

Log a completed task as done, optionally specifying project and session details, and return the recorded task.

Instructions

Log something you already finished as a done task (it shows up in Recap) and return it. Status is always done; relative-time params set when it happened. For in-progress work use karea_doing instead.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
sourceNoWhere it happened
toolTypeNoOptional: your AI provider ("claude-code" / "opencode" / "codex" / "cursor" / "aider" / "other"). Required when aiSessionId is supplied.
projectIdNoProject name or ID
aiSessionIdNoOptional: your current AI CLI session ID. When paired with toolType, atomically links this session to the affected task (equivalent to calling karea_link_session, but saves the round-trip). For Claude Code use the id from `claude --resume`.
descriptionYesWhat you did
sessionLabelNoOptional short label for the linked session (e.g. "Feature draft").

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed3 schema fields changedv1.0.2
    • addedInput schema / properties / aiSessionId
      Added value: +{
+  "description": "Optional: your current AI CLI session ID. When paired with toolType, atomically links this session to the affected task (equivalent to calling karea_link_session, but saves the round-trip). For Claude Code use the id from `claude --resume`.",
+  "type": "string"
+}
    • addedInput schema / properties / sessionLabel
      Added value: +{
+  "description": "Optional short label for the linked session (e.g. \"Feature draft\").",
+  "type": "string"
+}
    • addedInput schema / properties / toolType
      Added value: +{
+  "description": "Optional: your AI provider (\"claude-code\" / \"opencode\" / \"codex\" / \"cursor\" / \"aider\" / \"other\"). Required when aiSessionId is supplied.",
+  "enum": [
+    "claude-code",
+    "opencode",
+    "codex",
+    "cursor",
+    "aider",
+    "other"
+  ],
+  "type": "string"
+}
  2. First observedv1.0.0

TDQS

A4.6/5.0
Behavior4/5

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

Despite no annotations, the description discloses key behavior: status is always done, relative-time params set timing, and the tool returns the task. It could mention return format or side effects, but overall adequate.

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 sibling reference, all essential. Front-loaded with purpose and key behavior, no wasted words.

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?

Covers purpose, usage, and key behavior for a 6-param tool with no output schema. Omits specifics of 'relative-time params' but overall sufficient for correct invocation.

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%, but the description adds meaning: it contextualizes parameters (status always done, relative-time params) and explains the aiSessionId+toolType combo saves a round-trip. This goes beyond basic schema explanations.

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 logs a completed task ('Log something you already finished as a done task') and distinguishes it from siblings like karea_doing ('For in-progress work use karea_doing instead').

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?

Explicitly tells when to use (for finished tasks) and when not to (in-progress work) with a direct alternative: 'For in-progress work use karea_doing instead.'

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