Skip to main content
Glama
tasklite-net

TaskLite MCP

by tasklite-net
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

query_items

Read-only

Fetch board items with cell values, filterable by search, status, priority, and archived status. Supports pagination and sorting.

Instructions

List items (rows) of a board, including their cell values. Returns all items unless limit/page are given (the API defaults to 50 per page when unpaged, so the tool pages through and concatenates). Narrow the result with search, status, priority and sort instead of fetching everything. This is the admin view; the REST endpoints of a published app take a fuller grammar — filter[column][gte], relation filters, per-field search — see get_app_spec.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
pageNo1-based page, only with limit
sortNoSort by title, createdAt, updatedAt or status; prefix with "-" for descending, e.g. "-createdAt". Anything else keeps the board order
limitNoPage size; omit to fetch all items
searchNoFree text; matches the row title and its text cells
statusNoOnly rows with one of these statuses, comma separated: "todo,in_progress" (task boards only)
boardIdYesBoard id (from list_boards / create_board)
archivedNoWhich rows to include. Default active
priorityNoOnly rows with one of these priorities, comma separated (task boards only)
projectIdYesProject id (from list_projects / create_project)

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed7 schema fields changedv0.13.0
    • addedInput schema / properties / archived
      Added value: +{
+  "description": "Which rows to include. Default active",
+  "enum": [
+    "active",
+    "archived",
+    "all"
+  ],
+  "type": "string"
+}
    • addedInput schema / properties / boardId / description
      Added value: +"Board id (from list_boards / create_board)"
    • addedInput schema / properties / priority
      Added value: +{
+  "description": "Only rows with one of these priorities, comma separated (task boards only)",
+  "type": "string"
+}
    • addedInput schema / properties / projectId / description
      Added value: +"Project id (from list_projects / create_project)"
    • addedInput schema / properties / search
      Added value: +{
+  "description": "Free text; matches the row title and its text cells",
+  "type": "string"
+}
    • addedInput schema / properties / sort
      Added value: +{
+  "description": "Sort by title, createdAt, updatedAt or status; prefix with \"-\" for descending, e.g. \"-createdAt\". Anything else keeps the board order",
+  "type": "string"
+}
    • addedInput schema / properties / status
      Added value: +{
+  "description": "Only rows with one of these statuses, comma separated: \"todo,in_progress\" (task boards only)",
+  "type": "string"
+}
  2. First observedv0.7.0

TDQS

A4.7/5.0
Behavior4/5

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

Annotations already mark readOnly=true and destructiveHint=false. The description adds useful behavioral context about pagination defaults (50 per page, auto-pagination) and notes it is the admin view, but does not mention auth or rate limits.

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 compact yet information-dense, front-loading the core purpose and then adding pagination, filtering, and admin-view context without fluff or redundancy.

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?

Despite having no output schema, the description sufficiently covers the tool's behavior: what it returns, pagination, filtering options, and when to use it. It also points to get_app_spec for advanced filtering, making it complete for the intended use.

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 description coverage is 100% with detailed parameter descriptions (e.g., sort format, status/priority task-board-only). The tool description adds a couple of behavioral nuances (page only with limit, omit limit to fetch all), slightly enriching beyond the schema.

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 'List items (rows) of a board' with a specific verb 'list' and resource 'board'. It distinguishes from sibling tools like create_item and get_board_schema, and clarifies it is the admin view.

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 explains when to use this tool (to list items, with pagination and filtering), advises narrowing results instead of fetching everything, and points to get_app_spec for more advanced REST grammar, making the when/where alternatives clear.

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