Skip to main content
Glama
opositatest

swimlane-mcp

by opositatest
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

search_tasks

Read-onlyIdempotent

Find KanbanFlow tasks by text across selected boards and columns, matching query words in names, descriptions, labels, custom fields, or subtasks. Read-only.

Instructions

Finds tasks whose text contains a query, across every configured KanbanFlow board and column (or the boards and columns you choose). The query is split into words and, by default, all of them must appear somewhere in the fields you pick (fields, default name and description; labels, custom field values and subtask names are available too). Each task says in matchedFields which fields contained part of the query. KanbanFlow has no search endpoint, so tasks are loaded and filtered here: the counts cover only what was loaded, and meta reports failed boards and columns that came partially loaded (typically "done") with how to load them completely. Read-only. To search comments or mentions, use list_comments instead.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
limitNoMaximum tasks returned (default 50, max 500). Counts always cover every match.
queryYesText to find in the tasks, case-insensitive and as a substring. It is split into words; by default every word has to appear somewhere in the searched fields (AND).
boardsNoBoard ids or exact names to search (see list_boards). Default: every configured board.
detailNo"summary" (default) trims descriptions. "full" adds the complete description and the raw API object.
fieldsNoWhere to look (default ["name", "description"]). "labels" searches the label names, "customFields" the custom field values (names are not in the API) and "subTasks" the subtask names.
personNoOnly tasks of this person (responsible user or any collaborator): id, email, full name or part of the name. "me" uses the configured user. Default: everybody.
columnsNoColumn ids or exact names (case-insensitive). Default: every column. Limited columns listed here (usually "done") are loaded completely.
loadAllPagesNoLoad every limited column completely (slow on big boards).

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.2.0

TDQS

A4.8/5.0
Behavior5/5

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

Goes well beyond the readOnly/openWorld annotations by disclosing that KanbanFlow has no search endpoint, that work is client-side, that counts only cover loaded data, and that meta reports failed boards and partially loaded columns. It also notes read-only status and the matchedFields return hint.

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?

Dense but front-loaded: purpose, then matching semantics, then the local-filtering caveat, then the sibling pointer. Every sentence carries information, though the long middle sentences about loading behavior take effort to parse.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With no output schema, the description compensates by explaining matchedFields and meta, and it covers the limiting/loading trade-offs of an 8-parameter tool. Nothing essential to selecting or invoking it is missing.

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%, so the baseline is 3, but the description adds real meaning: query words are AND-combined by default, labels/customFields/subTasks map to specific values, and limited columns listed are loaded completely. It does not restate every parameter, but it clarifies the ambiguous ones.

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?

States a specific verb and resource ("Finds tasks whose text contains a query") plus scope (all configured boards/columns or chosen ones). It also differentiates from the sibling list_comments by naming it and the case it covers.

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 routes to the alternative: "To search comments or mentions, use list_comments instead." Default behavior for boards, columns, fields and person is spelled out, so an agent knows when this tool applies and when it does not.

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