Skip to main content
Glama

List Cards

fizzy_get_cards
Read-only

Fetch a paginated list of cards, filtering by board, column, assignees, tags, index, or search terms. Use summary fields for lightweight scans, and paginate via next_page until has_more is false.

Instructions

Get a page of cards in an account with optional filtering by board, indexed_by (e.g., 'golden' for priority cards), column, assignees, tags, or search terms. search OR-matches its words by default; set search_mode='all' to require every usable word (stopwords and words under 3 characters are dropped and listed in ignored_search_terms), which is the mode to use when checking whether a card already exists. Use board_id to scope results to a specific board and column_id to scope to a workflow column. Results are PAGINATED with a server-controlled, variable page size, so never compute a page count from the length of one page. Returns an object {cards, page, total_count, has_more, next_page}, where total_count is the total number of cards matching the filters (NOT the length of this page). To enumerate every match, call repeatedly with page = next_page until has_more is false OR cards comes back empty — an out-of-range page returns empty cards but may still report has_more true. A board's cards_count from fizzy_get_boards can exceed a single page of results; that is expected, not a discrepancy. Use fields='summary' when browsing, searching, or scanning many cards — it drops full descriptions/HTML and returns a much smaller payload (often 100x+ smaller). Once you've identified the specific card you need, call fizzy_get_card for its full detail.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
pageNoPage number to fetch (1-based). Card listings are paginated with a server-controlled, variable page size (early pages are small, e.g. 15 cards; later pages are larger). Omit for the first page; pass the next_page value from the previous response to fetch subsequent pages.
fieldsNoResponse projection. 'full' (the default — used when this parameter is omitted) returns every field exactly as the API provides it, unchanged from prior behavior. 'summary' strips large, rarely-needed fields — full HTML/rich-text bodies and descriptions, duplicated plain-text/HTML pairs, and repeated embedded objects like the full creator or card — keeping only IDs, names, and short previews. Summary responses are typically 4x to over 100x smaller depending on the tool. Prefer 'summary' when scanning, searching, or listing many results; switch to 'full' (or a single-item fetch tool) once you need complete detail on a specific item.
searchNoText search over card titles, descriptions and comments. Fizzy splits the input on whitespace and punctuation (hyphens included), stems the words, and OR-matches them; results are ordered by last activity, not relevance. There is no phrase or exact-match syntax, and quotes are ignored. A multi-word or hyphenated query is therefore a broad recall query: total_count > 0 does not prove the exact string exists. For an existence check, set search_mode to 'all' or search a single distinctive alphanumeric token, and confirm the match in the returned cards. Omit to return all cards (subject to other filters).
tag_idsNoFilter cards by tags. Provide an array of tag IDs. Only returns cards that have ANY of the specified tags (OR logic). Omit to include cards regardless of tags.
board_idNoFilter cards by board. Only returns cards belonging to the specified board. Get available board IDs from fizzy_get_boards. Omit to include cards from all boards.
column_idNoFilter cards by workflow column. Only returns cards in the specified column. Omit to include cards from all columns and triage.
indexed_byNoFilter cards by special index. Options: 'all' = all cards including closed, 'closed' = only closed/archived cards, 'not_now' = cards in Not Now triage, 'stalled' = cards with no recent activity, 'postponing_soon' = cards nearing their board's auto-postpone period (about to move to Not Now), 'golden' = priority/important cards marked as golden
search_modeNoHow the words of `search` combine. 'any' (default) sends the whole string as one term, which Fizzy OR-matches word by word. 'all' splits it on whitespace and punctuation and requires every usable word to match, which makes search usable as an existence check before creating a card (still confirm the match in the returned cards: words are stemmed, not matched exactly). In 'all' mode, words shorter than 3 characters and MySQL full-text stopwords (the, to, with, for, ...) are dropped before the request because on their own they match nothing and would empty the result; the response then includes search_terms (sent) and ignored_search_terms (dropped). Errors if no usable word remains. Has no effect without `search`.
account_slugYesThe account slug identifier (e.g., '123456' or '/123456'). This identifies which Fizzy account to operate on. Get available account slugs from fizzy_get_identity or fizzy_get_accounts.
assignee_idsNoFilter cards by assigned users. Provide an array of user IDs. Only returns cards assigned to ANY of the specified users (OR logic). Omit to include cards regardless of assignments.

Schema Changelog

Changes observed during successful MCP inspections. Dates show when Glama detected each change.

  1. First observedv1.1.0

TDQS

A4.9/5.0
Behavior5/5

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

Annotations cover readOnly/destructive safety, so the description's job is behavioral nuance — and it delivers extensively: server-controlled variable page size, total_count meaning vs page length, out-of-range pages returning empty cards while has_more may stay true, search OR-matching and stemming, stopword dropping with ignored_search_terms, and fields='summary' payload reduction. No contradiction with the readOnlyHint=true annotation.

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?

Around 230 words covering a 10-parameter tool with real pagination traps. Every sentence earns its place: core action first, then filters, then search semantics, then pagination mechanics, then performance guidance and handoff. Nothing is fluff, and the density is justified by the operational traps it prevents.

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 fully carries the return-value burden and does so explicitly: returns {cards, page, total_count, has_more, next_page}, explains total_count semantics, and gives the exact enumeration loop ('call repeatedly with page = next_page until has_more is false OR cards comes back empty'). Complex tool, no gaps.

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 — the schema already documents every parameter thoroughly. The description adds value beyond the schema by wiring parameters to use cases (search_mode='all' for existence checks, fields='summary' for large scans, board_id sourced from fizzy_get_boards) and clarifying cross-parameter behavior, but it does not add per-parameter syntax details the schema lacks.

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 ('Get a page of cards in an account') plus the full set of filter dimensions. It also explicitly distinguishes itself from fizzy_get_card ('call fizzy_get_card for its full detail'), so an agent can tell them apart without opening schemas.

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?

Gives explicit when-to-use advice: fields='summary' when browsing/scannery many cards, search_mode='all' when checking whether a card already exists, and a clear handoff to fizzy_get_card once the specific card is identified. This is actionable routing guidance, not vague context.

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

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/Fabric-Pro/fizzy-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server