Skip to main content
Glama

tasks_search

Read-only

Search and filter tasks by status, text content, or ID within the MCP Tasks server to find specific items in your task management system.

Instructions

Search tasks from specific statuses with optional text & ID filtering

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()
statusesNoSpecific statuses to get. Gets all if omitted
termsNoSearch terms to filter tasks by text or status (case-insensitive, OR logic, no regex or wildcards)
idsNoOptional list of task IDs to search for
limitNoMaximum number of results (only for really large task lists)

Implementation Reference

  • The handler function implementing the core logic of the 'tasks_search' tool (internally 'search'). It loads metadata, filters tasks by statuses, IDs, search terms using fuzzy search, applies limit, and returns matching tasks.
    handler: (args) => {
      const meta = metadata.load(args.source_id)
      const groups = args.statuses?.length ? args.statuses : meta.statuses
      let results = groups.flatMap(status => meta.groups[status] || [])
    
      if (args.ids) {
        results = results.filter(task => args.ids!.includes(task.id))
      }
    
      if (args.terms?.length) {
        results = results.filter(task => args.terms!.some(term =>
          util.fuzzySearch(`${task.text} ${task.status}`, term),
        ))
      }
      if (args.limit) {
        results = results.slice(0, args.limit)
      }
      return results
  • Zod input schema defining parameters for the 'tasks_search' tool: source_id, statuses, terms, ids, limit.
    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)'),
    }),
  • src/server.ts:15-42 (registration)
    Registration loop in the MCP server that adds the 'tasks_search' tool (along with others) to the FastMCP server using server.addTool, providing name (tasks_search if prefixed), description, parameters (schema), and execute wrapper.
    // Register all tools & resources
    for (const tool of Object.values(tools)) {
      if (!tool.isEnabled) {
        continue
      }
      if (tool.isResource) {
        // Register as resource
        server.addResource({
          uri: `resource://${tool.name}`,
          name: tool.description,
          mimeType: 'text/plain',
          load: () => cli.runTool(tool, []).then(text => ({ text })),
        })
      } else {
        // Register as tool with enhanced logging
        server.addTool({
          annotations: {
            openWorldHint: false, // This tool doesn't interact with external systems
            readOnlyHint: tool.isReadOnly,
            title: tool.name,
          },
          name: tool.name,
          description: tool.description,
          parameters: tool.schema,
          execute: (args) => cli.runTool(tool, args),
        })
      }
    }
  • Helper function defineTool that wraps the tool definition, sets the name to 'tasks_search' if PREFIX_TOOLS is enabled, and adds default properties.
    function defineTool<S extends ZodSchema>(name: string, tool: {
      schema: S
      description: string
      isResource?: boolean
      isReadOnly?: boolean
      isEnabled?: boolean
      handler: (args: z.infer<S>, context?: any) => any
      fromArgs: (args: string[]) => z.infer<S>
    }) {
      const toolName = env.PREFIX_TOOLS ? `tasks_${name}` : name
      return {
        ...tool,
        name: toolName,
        isResource: tool.isResource ?? false,
        isReadOnly: tool.isReadOnly ?? false,
        isEnabled: tool.isEnabled ?? true,
      }
    }
Behavior3/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 read operation. The description adds context about filtering capabilities (statuses, text, IDs) and hints at default behavior ('Gets all if omitted' for statuses), but doesn't disclose rate limits, pagination, or error handling. With annotations covering safety, the description provides moderate additional value without contradictions.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, efficient sentence that front-loads the core functionality ('Search tasks from specific statuses') and includes key optional features. There's no wasted language, but it could be slightly more structured (e.g., separating core vs. optional aspects). Overall, it's appropriately concise and clear.

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 moderate complexity (5 parameters, no output schema), the description covers the basic purpose and filtering options. However, it lacks details on return format, error cases, or prerequisites (e.g., needing source_id from task_setup, as hinted in the schema). With annotations providing safety context but no output schema, the description is adequate but leaves gaps for full agent understanding.

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?

Schema description coverage is 100%, so parameters are fully documented in the schema. The description mentions 'optional text & ID filtering,' which aligns with the 'terms' and 'ids' parameters but doesn't add meaning beyond what the schema provides (e.g., no extra syntax or format details). With high schema coverage, the baseline score of 3 is appropriate as the description doesn't significantly enhance parameter understanding.

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 verb ('Search') and resource ('tasks'), and specifies filtering by statuses with optional text and ID filtering. It distinguishes itself from siblings like tasks_add (create) and tasks_update (modify), but doesn't explicitly contrast with tasks_summary which might also retrieve tasks. The purpose is clear but sibling differentiation could be more explicit.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies usage context through 'Search tasks from specific statuses,' suggesting this tool is for filtered retrieval rather than creation or modification. However, it doesn't provide explicit guidance on when to use this versus tasks_summary (which might summarize tasks) or when not to use it (e.g., for unfiltered lists). Usage is implied but not clearly articulated with alternatives or exclusions.

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