Serverless AI agent for task management using Google Gemini with AWS Lambda and DynamoDB backend
This server has basic tool definitions with schemas and descriptions present, but falls short of production quality. All 4 tools have descriptions (10-60 chars, below the 50-200 char baseline for LLM optimization) and input schemas with typed parameters. However, descriptions lack actionable context, they state WHAT but not WHEN or WHY. Parameter descriptions are minimal (e.g., 'The ID of the task to update' for updateTask.id). No output schemas are documented. Error handling is absent from tool definitions. The executor catches errors but provides no recovery guidance. Naming is clear (verb_noun pattern: createTask, listTasks, updateTask, deleteTask) but descriptions don't explain dependencies or side effects. No enum constraints on status parameter despite accepting only 'pending', 'in-progress', 'completed'. Missing idempotency guidance for destructive operations.
Creates a new task with a title and optional description
Deletes a task by ID
Gets all tasks from the database
Updates an existing task's title, description, or status
Descriptions are too short (10-60 chars vs. 50-200 char baseline) and lack actionable context. 'Gets all tasks from the database' doesn't explain when to call it or what structure it returns. LLMs cannot optimize tool selection without richer guidance.
No output schemas documented. Callers don't know what fields to expect from createTask, listTasks, updateTask, or deleteTask responses. This forces LLMs to guess downstream field names and risks broken tool chains.
updateTask.status accepts free-form strings instead of an enum constraint. Description says 'pending, in-progress, completed' but doesn't enforce it. LLMs may pass invalid values like 'done' or 'pending_review', causing silent failures.
Inferred effective spec: 2026-07-28+.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | F | 43 | 2026-07-28+ | v2 |
No error handling guidance in tool definitions. executor.ts catches errors but returns raw exceptions. LLMs receive no recovery hints (e.g., 'Task not found. Try listTasks() first' or 'Invalid ID format').
deleteTask lacks confirmation or dry-run support. Agents can permanently delete tasks without a safety gate. No idempotency guidance, retrying a failed delete may succeed on the second attempt, causing unintended data loss.