Skip to main content
Glama
Cafelatte1

FronyBoard

by Cafelatte1
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Hybrid

search_tasks

Find tasks by matching text across all projects when you remember a word but not the task ID or project; narrow results by project or status.

Instructions

Use it when the user remembers a word from a task but not its id or project (find a task).

Find tasks by text across all projects, with the dashboard's rules: case-insensitive
substring over project key, task id, title and content (not branch or tags); a
matching project key returns all of its tasks. Closed periods are included; cancelled
tasks only with `include_cancelled` (or `status='cancelled'`).

Hits are compact, ordered by project, then in_progress -> blocked -> todo
-> done -> cancelled, then id; `match` says which field hit; a task's one-line `content`
is included when it has one. `key` narrows to one project, `limit` (default 20) caps the
hits while `count` still reports the total. Follow up with get_task for the full record.

Input Schema

NameRequiredDescriptionDefault
keyNo
limitNo
queryYes
statusNo
include_cancelledNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.5/5.0
Behavior5/5

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

With no annotations, the description carries the full burden and does so well: it discloses the matching rules (case-insensitive substring over project key, task id, title, content; excludes branch/tags), the project-key shortcut, inclusion of closed periods, cancelled-task gating, result ordering, the `match` field and compact hit shape. This is unusually rich behavioral disclosure for a search tool.

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 front-loaded with the use case, then moves to matching semantics, inclusion rules, and result shape in a logical order. It is dense but every clause carries information; only the long parenthetical matching sentence is slightly overloaded.

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 5-parameter search tool with no output schema and no annotations, it covers the essential behavior: matching, ordering, returned fields (`match`, `content`, `count`), and follow-up guidance. It omits permissions/auth expectations and error or empty-result behavior, which are minor for a read search.

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 0%, so the description must compensate, and it largely does: it explains `query` as text search, `key` as a project narrowing filter, `limit` (default 20) as a hit cap, `include_cancelled`, and `status='cancelled'`. The `status` parameter's full accepted value set is only implied by the ordering list, so a small gap remains.

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 states a specific verb and resource — find tasks by text — and frames the exact user situation ('remembers a word from a task but not its id or project'). It clearly distinguishes itself from get_task, which it names as the follow-up for full records.

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

Usage Guidelines4/5

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

It gives a concrete trigger ('when the user remembers a word from a task but not its id or project') and routes to get_task for full details. It does not explicitly contrast with list_tasks or state when a plain listing is preferable, which keeps it from a 5.

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