Skip to main content
Glama

List Todos

list_todos

Retrieve all todo items in an organized format to view current tasks and track progress efficiently.

Instructions

Return all todos in a structured format.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
todosYes

Implementation Reference

  • src/server.ts:53-70 (registration)
    Registration of the 'list_todos' tool using server.registerTool, including schema and handler.
    server.registerTool(
      "list_todos",
      {
        title: "List Todos",
        description: "Return all todos in a structured format.",
        inputSchema: {},
        outputSchema: {
          todos: z.array(TodoSchema),
        },
      },
      async () => {
        const todos = await readTodos();
        return {
          structuredContent: { todos },
          content: [{ type: "text", text: JSON.stringify({ todos }, null, 2) }],
        };
      }
    );
  • The handler function for 'list_todos' that reads todos from storage and returns structured content.
    async () => {
      const todos = await readTodos();
      return {
        structuredContent: { todos },
        content: [{ type: "text", text: JSON.stringify({ todos }, null, 2) }],
      };
    }
  • Zod schema for Todo type, used in the outputSchema of list_todos.
    export const TodoSchema = z.object({
      id: z.number().int().positive(),
      title: z.string().min(1),
      done: z.boolean(),
    });
  • Helper function to read todos from the JSON file database.
    async function readTodos(): Promise<Todo[]> {
      try {
        const s = await fs.readFile(DB_PATH, "utf-8");
        return JSON.parse(s);
      } catch {
        return [];
      }
    }
  • Tool metadata including title, description, inputSchema (empty), and outputSchema referencing TodoSchema.
    {
      title: "List Todos",
      description: "Return all todos in a structured format.",
      inputSchema: {},
      outputSchema: {
        todos: z.array(TodoSchema),
      },
    },
Behavior2/5

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

With no annotations, the description carries full burden but only states the basic action. It does not disclose behavioral traits such as whether it returns all todos at once or paginates, if it requires authentication, rate limits, or error handling. This leaves significant gaps for a tool that likely interacts with data.

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 a single, efficient sentence with zero waste. It is front-loaded, directly stating the purpose without unnecessary details. Every word earns its place, making it easy to parse quickly.

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?

Given the tool's simplicity (0 parameters, output schema exists), the description is minimally adequate. However, with no annotations and siblings implying data operations, it should ideally mention safety (e.g., read-only) or constraints. The output schema helps, but the description lacks context for usage in a todo management system.

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?

The input schema has 0 parameters with 100% coverage, so no parameter documentation is needed. The description adds value by specifying 'all todos' and 'structured format', which clarifies scope and output beyond the schema. Baseline is high due to no parameters, but it compensates with useful context.

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 action ('Return') and resource ('all todos'), specifying the output format ('structured format'). It distinguishes from siblings like add_todo or remove_todo by focusing on retrieval rather than modification. However, it lacks explicit sibling differentiation, such as noting this is for unfiltered listing versus other query options.

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 is provided on when to use this tool versus alternatives. It does not mention prerequisites, context (e.g., after adding todos), or exclusions (e.g., for filtered views). The agent must infer usage from the name and siblings alone, which is insufficient for clear decision-making.

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

Install Server

Other Tools

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/CalamityAdam/mcp-todo'

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