Skip to main content
Glama

tasks_summary

Read-only

Get task counts by status and identify work-in-progress tasks to track project progress and manage workflow effectively.

Instructions

Get per-status task counts and the WIP task(s). Redundant right after tasks_add/tasks_update

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
source_idNoSource ID from task_setup() response - Defaults to most recent in the workspace if not provided - Try to always provide it! - If you don't have it, ask the user for a file path and call task_setup()

Implementation Reference

  • src/tools.ts:153-163 (registration)
    Tool registration for 'summary', automatically prefixed to 'tasks_summary' via defineTool based on env.PREFIX_TOOLS (default: true). Includes schema, description, read-only flag, and handler delegating to getSummary.
    summary: defineTool('summary', {
      schema: z.object({
        source_id: schemas.sourceId,
      }),
      fromArgs: () => ({}),
      description: 'Get per-status task counts and the WIP task(s). Redundant right after tasks_add/tasks_update',
      isReadOnly: true,
      handler: (args) => {
        return getSummary(args.source_id)
      },
    }),
  • Core handler logic for tasks_summary: loads metadata, computes per-status task counts, total tasks, WIP tasks, and returns JSON summary.
    function getSummary(sourceId?: string, extra?: object) {
      const meta = metadata.load(sourceId)
      const counts = _.mapValues(meta.groups, tasks => tasks.length)
      const total = Object.values(counts).reduce((sum, count) => sum + count, 0)
      const wip = _.camelCase(env.STATUS_WIP)
      return JSON.stringify({
        source: _.omit(meta.source, ['workspace']),
        ...counts, total, ...extra,
        instructions: env.INSTRUCTIONS || undefined,
        reminders: env.STATUS_REMINDERS ? meta.groups[env.STATUS_REMINDERS] : undefined,
        [wip]: meta.groups[env.STATUS_WIP],
      })
    }
  • Zod input schema for tasks_summary tool: requires optional source_id (defaults to most recent).
    schema: z.object({
      source_id: schemas.sourceId,
    }),
  • src/tools.ts:15-42 (registration)
    MCP server registration loop that adds all enabled tools from tools.ts (including tasks_summary) to the FastMCP server using server.addTool.
      schema: z.object({
        workspace: z.string().optional().describe('Workspace/project directory path (provided by the IDE or use $PWD)'),
        source_path: schemas.sourcePath,
      }),
      fromArgs: ([sourcePath, workspace]) => ({ source_path: sourcePath, workspace: workspace || undefined }),
      description: util.trimLines(`
        Initializes an source file from a path
        - Always call once per conversation when asked to use these tools
        - Ask the user to clarify the file path if not given, before calling this tool
        - Creates the file if it does not exist
        - Returns the source ID for further use
        ${env.INSTRUCTIONS ? `- ${env.INSTRUCTIONS}` : ''}
      `),
      handler: (args) => {
        storage.getParser(args.source_path)
        // Register the source and get ID
        const source = sources.register(args.source_path, args.workspace)
        return getSummary(source.id)
      },
    }),
    
    search: defineTool('search', {
      schema: z.object({
        source_id: schemas.sourceId,
        statuses: z.array(schemas.status).optional().describe('Specific statuses to get. Gets all if omitted'),
        terms: z.array(z.string()).optional().describe('Search terms to filter tasks by text or status (case-insensitive, OR logic, no regex or wildcards)'),
        ids: schemas.ids.optional().describe('Optional list of task IDs to search for'),
        limit: z.number().int().min(1).optional().describe('Maximum number of results (only for really large task lists)'),
  • sourceId schema reused in tasks_summary input: string ID from setup, optional.
    sourceId: z.string().min(1).optional().describe(util.trimLines(`
      Source ID from task_setup() response
      - Defaults to most recent in the workspace if not provided
      - Try to always provide it!
      - If you don't have it, ask the user for a file path and call task_setup()
    `)),
Behavior4/5

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

Annotations already declare readOnlyHint=true and openWorldHint=false, indicating a safe, bounded operation. The description adds valuable behavioral context about redundancy patterns that annotations don't cover, though it doesn't mention performance characteristics like caching or rate limits that would be helpful.

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 extremely concise (two brief sentences) and front-loaded with the core purpose. Every word earns its place, with the second sentence providing crucial usage guidance without unnecessary elaboration.

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 read-only tool with good annotations and full schema coverage, the description provides adequate context about purpose and usage patterns. The main gap is lack of output format details (no output schema exists), but the description does specify what information will be returned (counts and WIP tasks).

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?

With 100% schema description coverage, the schema fully documents the single parameter. The description adds no parameter-specific information beyond what's in the schema, so it meets the baseline expectation without adding extra semantic value.

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 with specific verbs ('Get per-status task counts and the WIP task(s)') and distinguishes it from siblings by explicitly mentioning redundancy with tasks_add/tasks_update. It identifies both the quantitative output (counts) and qualitative output (WIP tasks).

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?

The description provides explicit guidance on when NOT to use this tool ('Redundant right after tasks_add/tasks_update'), which helps the agent avoid unnecessary calls. It also implies usage context by contrasting with sibling operations, though it doesn't name specific alternatives for all scenarios.

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/flesler/mcp-tasks'

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