Skip to main content
Glama
davegomez

fizzy-mcp

by davegomez
OverviewSchemaRelated ServersScoreDiscussions
TypeScript
Remote

fizzy_task

Create or update kanban cards with control over status, tags, steps, and column placement. Automatically detects create or update mode based on card number.

Instructions

Create or update a card with full control over status, tags, steps, and column placement.

Mode detection:

  • card_number absent → CREATE mode (requires board_id + title)

  • card_number present → UPDATE mode

Create mode: Creates card, then best-effort: adds steps, toggles tags, triages to column.

Update mode: Updates title/description if provided. Changes status (open/closed/not_now). Manages tags with add/remove. Moves card to column (from inbox or another column). Same-column moves are skipped.

Fizzy column conventions:

  • Maybe? (inbox): Cards with no column_id. This is where new cards start.

  • Not Now: Set status: "not_now" to move here (defers the card).

  • Done: Set status: "closed" to move here (completes the card).

  • Custom columns: Use column_id from fizzy_boards to triage to workflow columns.

Arguments:

  • account_slug (optional): Uses session default if omitted

  • card_number (optional): Card to update. Omit to create new card.

  • board_id (optional): Board ID. Required for create mode.

  • title (optional): Card title. Required for create mode.

  • description (optional): Card body in markdown

  • status (optional): open | closed | not_now — changes card lifecycle state

  • column_id (optional): Move card to this column (works from inbox or other columns; skipped if already there)

  • position (optional): top | bottom (default: bottom) — position in column

  • add_tags (optional): Tag titles to add

  • remove_tags (optional): Tag titles to remove

  • steps (optional): Checklist items to create (create mode only)

Returns: JSON with mode, card (id, number, title, url, status), operations summary, failures array.

Examples: Create: {board_id: "...", title: "New task", steps: ["Step 1", "Step 2"]} Update: {card_number: 42, status: "closed", add_tags: ["done"]}

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
account_slugNoAccount slug. Uses session default if omitted.
card_numberNoCard number to update. Omit to create a new card.
board_idNoBoard ID. Required when creating a new card.
titleNoCard title (1-500 chars). Required when creating.
descriptionNoCard body in markdown (max 10000 chars).
statusNoCard status: open | closed | not_now.
column_idNoColumn ID to triage card to.
positionYesPosition in column: top | bottom (default: bottom).bottom
add_tagsNoTag titles to add to the card.
remove_tagsNoTag titles to remove from the card.
stepsNoChecklist steps to create (create mode only).

Tool Definition Quality

A4.6/5.0
Behavior4/5

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

No annotations provided, so description carries full burden. Details mode detection, best-effort operations, update behavior (skip same-column moves), and column conventions. Lacks error handling or auth requirements.

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?

Well-structured with headers, bullet arguments, and examples. Every sentence adds value; no 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?

Covers all aspects: mode detection, creation/update specifics, column conventions, parameter meanings, return format, and examples. Complete for a moderately complex tool with no annotations or output schema.

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

Parameters5/5

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

Schema coverage is 100%, and description adds value by grouping parameters (e.g., create-mode required, update-mode optional), explaining enum meanings (open/closed/not_now), and clarifying steps is create-mode only.

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 it creates or updates a card with full control, and distinguishes from siblings like fizzy_get_card (read-only) and fizzy_comment (commenting).

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?

Provides explicit mode detection and required parameters for create vs update, but does not explicitly state when to use alternative tools like fizzy_get_card or fizzy_search.

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

Install Server

Other Tools

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

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