Skip to main content
Glama

list_space_cards

Read-onlyIdempotent

Retrieve and filter cards in a Kaiten space using search, status, assignee, due date, board, lane, column, and pagination options.

Instructions

List cards in a space via the dedicated cards route, with search filters.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
asapNo
limitNo
queryNo
detailNo
offsetNo
statesNo
lane_idNo
overdueNo
tag_idsNo
type_idNo
archivedNo
board_idNo
order_byNo
owner_idNo
space_idYes
type_idsNo
column_idNo
conditionNo
owner_idsNo
column_idsNo
member_idsNo
done_on_timeNo
text_offsetsNoJSON pointer -> character offset. Reuse the same page and all returned text cursors to continue.
created_afterNo
previous_pageNoPass page_fingerprint from the preceding page to detect an API ignoring pagination.
search_fieldsNo
updated_afterNo
with_due_dateNo
created_beforeNo
due_date_afterNo
responsible_idNo
updated_beforeNo
due_date_beforeNo
order_directionNo
responsible_idsNo
section_offsetsNoJSON pointer -> nested array offset. Reuse the same page to continue a section.
exclude_lane_idsNo
exclude_board_idsNo
exclude_column_idsNo
last_moved_to_done_at_afterNo
last_moved_to_done_at_beforeNo
first_moved_in_progress_afterNo
first_moved_in_progress_beforeNo

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
itemNo
errorNo
itemsNo
limitNo
totalNo
offsetNo
metadataNo
warningsNo
paginationNo
next_offsetNo
continuationNo
comments_limitNo
comments_offsetNo
page_fingerprintNo
comments_includedNo
next_text_offsetsNo
comments_next_offsetNo
total_in_selected_pagesNo
comments_page_fingerprintNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

C2.6/5.0
Behavior2/5

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false, and openWorldHint, covering the safety profile. The description adds almost no behavioral context beyond that: no pagination behavior, no note that limit caps at 100/defaults to 50, no ordering defaults, and no discussion of the large filter surface.

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

Conciseness3/5

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

The single sentence is front-loaded and waste-free, but for a tool with 43 parameters and heavy filter complexity it is under-specified rather than appropriately concise. Structure is fine; depth is not.

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

Completeness2/5

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

An output schema exists so return values need not be described, and annotations cover safety. But the massive filter/pagination surface with 7% schema coverage is left almost entirely unexplained, which is a substantial completeness gap for this complexity level.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is only 7% across 43 parameters. The description's generic 'with search filters' hints that filtering parameters exist but explains none of them (query, search_fields, states, type_ids, date ranges, offsets, etc.), leaving the agent to infer semantics from opaque names.

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 states a clear verb+resource: 'List cards in a space.' However, it offers no differentiation from closely related siblings like list_board_cards, search_cards, or get_card, and the phrase 'via the dedicated cards route' is internal jargon that adds nothing for an agent.

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

Usage Guidelines2/5

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

There is no guidance on when to use this tool versus search_cards or list_board_cards, both of which also list cards. The mention of 'search filters' arguably overlaps search_cards but the description never explains the distinction or any prerequisites.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.