Skip to main content
Glama
davegomez

fizzy-mcp

by davegomez
OverviewSchemaRelated ServersScoreDiscussions
TypeScript
Remote

fizzy-mcp

MCP server for Fizzy task management. Exposes 7 tools for managing boards, cards, comments, and checklists.

Prerequisites

Get your Fizzy access token:

  1. Log in to Fizzy

  2. Go to Settings > API Access

  3. Generate a new token

Related MCP server: Fizzy Do MCP

How to Install

Add to your config file:

  • macOS: ~/Library/Application\ Support/Claude/claude_desktop_config.json

  • Windows: %APPDATA%\Claude\claude_desktop_config.json

  • Linux: ~/.config/Claude/claude_desktop_config.json

{
  "mcpServers": {
    "Fizzy": {
      "command": "npx",
      "args": ["-y", "@silky/fizzy-mcp"],
      "env": {
        "FIZZY_TOKEN": "your-token-here"
      }
    }
  }
}

Windows only: Add "APPDATA": "C:\\Users\\YourUsername\\AppData\\Roaming" to the env block.

Restart Claude Desktop completely, then verify: "List my Fizzy boards."

Use the CLI:

claude mcp add --transport stdio Fizzy --env FIZZY_TOKEN=your-token-here -- npx -y @silky/fizzy-mcp

Or add to ~/.claude.json:

{
  "mcpServers": {
    "Fizzy": {
      "command": "npx",
      "args": ["-y", "@silky/fizzy-mcp"],
      "env": {
        "FIZZY_TOKEN": "your-token-here"
      }
    }
  }
}

Restart Claude Code, then verify: "List my Fizzy boards."

Add to ~/.cursor/mcp.json (global) or .cursor/mcp.json (project):

{
  "mcpServers": {
    "Fizzy": {
      "command": "npx",
      "args": ["-y", "@silky/fizzy-mcp"],
      "env": {
        "FIZZY_TOKEN": "your-token-here"
      }
    }
  }
}

Restart Cursor completely, then verify in Agent mode (Ctrl+I).

Add to .vscode/mcp.json in your workspace:

{
  "inputs": [
    {
      "type": "promptString",
      "id": "fizzy-token",
      "description": "Fizzy API Token",
      "password": true
    }
  ],
  "servers": {
    "Fizzy": {
      "command": "npx",
      "args": ["-y", "@silky/fizzy-mcp"],
      "env": {
        "FIZZY_TOKEN": "${input:fizzy-token}"
      }
    }
  }
}

Or use user settings via Command Palette → "MCP: Open User Configuration".

Add to ~/.codeium/windsurf/mcp_config.json:

{
  "mcpServers": {
    "Fizzy": {
      "command": "npx",
      "args": ["-y", "@silky/fizzy-mcp"],
      "env": {
        "FIZZY_TOKEN": "${env:FIZZY_TOKEN}"
      }
    }
  }
}

Set FIZZY_TOKEN in your shell environment, or hardcode the value. Restart Windsurf.

Add to the Cline MCP settings file:

  • macOS: ~/Library/Application Support/Code/User/globalStorage/saoudrizwan.claude-dev/settings/cline_mcp_settings.json

  • Windows: %APPDATA%/Code/User/globalStorage/saoudrizwan.claude-dev/settings/cline_mcp_settings.json

  • Linux: ~/.config/Code/User/globalStorage/saoudrizwan.claude-dev/settings/cline_mcp_settings.json

{
  "mcpServers": {
    "Fizzy": {
      "command": "npx",
      "args": ["-y", "@silky/fizzy-mcp"],
      "env": {
        "FIZZY_TOKEN": "your-token-here"
      },
      "disabled": false,
      "alwaysAllow": []
    }
  }
}

Add to .continue/config.yaml:

mcpServers:
  - name: Fizzy
    command: npx
    args:
      - "-y"
      - "@silky/fizzy-mcp"
    env:
      FIZZY_TOKEN: ${{ secrets.FIZZY_TOKEN }}

Requires pnpm.

git clone https://github.com/davegomez/fizzy-mcp.git
cd fizzy-mcp
pnpm install
pnpm build

Replace npx -y @silky/fizzy-mcp with node /absolute/path/to/fizzy-mcp/dist/index.js in any config above.

Configuration Reference

Variable

Required

Default

Description

FIZZY_TOKEN

Yes

—

API token from Fizzy settings

FIZZY_ACCOUNT

No

—

Default account slug (e.g., 897362094)

FIZZY_BASE_URL

No

https://app.fizzy.do

API base URL

Account Resolution

Tools resolve account_slug in this order:

  1. Explicit account_slug parameter on the tool call

  2. Session default (set via fizzy_account tool with action: "set")

  3. FIZZY_ACCOUNT environment variable

  4. Auto-detect (if user has exactly one account)

Tools Reference

fizzy_account

Gets, sets, or lists accounts for subsequent tool calls.

Parameter

Type

Required

Description

action

"get" | "set" | "list"

Yes

Action to perform

account_slug

string

For set

Account slug from Fizzy URL

Returns:

  • get: { "action": "get", "account_slug": "897362094" | null }

  • set: { "action": "set", "account_slug": "897362094" }

  • list: { "action": "list", "accounts": [{ "slug": "...", "name": "...", "id": "..." }] }

fizzy_boards

Lists boards in the account with column summaries.

Parameter

Type

Required

Default

Description

account_slug

string

No

Session default

Account slug

limit

number

No

25

Items per page (1-100)

cursor

string

No

—

Pagination cursor

Returns: { "items": Board[], "pagination": { "returned": number, "has_more": boolean, "next_cursor"?: string } }

fizzy_search

Searches for cards with filters.

Parameter

Type

Required

Description

account_slug

string

No

Account slug

board_id

string

No

Filter by board

tag_ids

string[]

No

Filter by ALL tags

assignee_ids

string[]

No

Filter by ANY assignees

creator_ids

string[]

No

Filter by card creator

closer_ids

string[]

No

Filter by who closed

card_ids

string[]

No

Filter to specific card IDs

indexed_by

"closed" | "not_now" | "all" | "stalled" | "postponing_soon" | "golden"

No

Filter by index

assignment_status

"unassigned"

No

Filter by assignment status

sorted_by

"newest" | "oldest" | "recently_active"

No

Sort order

terms

string[]

No

Free-text search terms

creation

date range*

No

Filter by creation date

closure

date range*

No

Filter by closure date

limit

number

No

Items per page (1-100, default 25)

cursor

string

No

Pagination cursor

*Date range values: today, yesterday, thisweek, thismonth, last7, last14, last30.

Returns: { "items": Card[], "pagination": {...} }

fizzy_get_card

Gets full details of a card by number or ID.

Parameter

Type

Required

Description

account_slug

string

No

Account slug

card_number

number

No*

Card number from URL (e.g., 42 from #42)

card_id

string

No*

Card UUID from API responses

*Provide card_number OR card_id. Prefer card_number when you have the human-readable # from the UI.

Returns: Card object with id, number, title, description (markdown), status, board_id, column_id, tags, assignees, steps_count, completed_steps_count, comments_count, url, timestamps.

fizzy_task

Creates or updates a card.

Mode: Omit card_number to create; include it to update.

Parameter

Type

Required

Description

account_slug

string

No

Account slug

card_number

number

No

Card to update (omit to create)

board_id

string

Create mode

Board for new card

title

string

Create mode

Card title

description

string

No

Markdown content

status

"open" | "closed" | "not_now"

No

Change card status

column_id

string

No

Triage to column

position

"top" | "bottom"

No

Position in column (default: "bottom")

add_tags

string[]

No

Tag titles to add

remove_tags

string[]

No

Tag titles to remove

steps

string[]

No

Checklist items (create mode only)

Returns: { "mode": "create" | "update", "card": {...}, "operations": {...}, "failures": [...] }

fizzy_comment

Create, list, update, or delete a comment on a card.

Parameter

Type

Required

Description

action

string

No

"create" (default), "list", "update", "delete"

account_slug

string

No

Account slug

card_number

number

Yes

Card number

comment_id

string

No

Comment ID. Required for update/delete

body

string

No

Comment in markdown (1-10000 chars). Required for create/update

Returns: Comment object with id, body (markdown), creator, timestamps, url. List returns { comments, pagination }. Delete returns { comment_id, deleted }.

fizzy_step

Create, complete, update, uncomplete, or delete a step on a card.

Parameter

Type

Required

Description

account_slug

string

No

Account slug

card_number

number

Yes

Card containing the step

step

string | number

No

Content substring OR 1-based index. Omit to create.

content

string

No

Step text for create or update

completed

boolean

No

Set completion state

delete

boolean

No

Delete the step

Mode detection:

  • step absent → CREATE (requires content)

  • step present, no other params → COMPLETE

  • step + content → UPDATE

  • step + completed: false → UNCOMPLETE

  • step + delete: true → DELETE

Returns: { "id": "...", "content": "...", "completed": true }

Pagination Reference

List operations return:

{
  "items": [...],
  "pagination": {
    "returned": 25,
    "has_more": true,
    "next_cursor": "opaque-cursor-string"
  }
}

Field

Type

Description

returned

number

Items in this response

has_more

boolean

More items available

next_cursor

string

Pass as cursor for next page

Error Reference

Error

Cause

"No account specified. Set FIZZY_ACCOUNT env var, use fizzy_account tool, or pass account_slug."

No account resolvable via any method

"Account "..." not found"

Invalid slug passed to fizzy_account set

"Card #N not found"

Card number does not exist

"Board not found"

Invalid board_id

License

AGPL-3.0-or-later

Available Tools

7 tools
fizzy_accountA

Get, set, or list accounts for API calls.

Manages the session default so you don't need to pass account_slug on every tool call.

When to use:

  • List available accounts to see what you have access to

  • Set working account after discovering accounts

  • Check current default before operations

Don't use when: Operating across multiple accounts simultaneously — pass account_slug explicitly instead.

Arguments:

  • action (required): "get" to check current default, "set" to change it, "list" to see available accounts

  • account_slug (required for set): Account slug (e.g., "897362094")

Returns:

  • get: { "action": "get", "account_slug": "897362094" } or null if not set

  • set: { "action": "set", "account_slug": "897362094" }

  • list: { "action": "list", "accounts": [{ "slug": "...", "name": "...", "id": "..." }] }

Related: Most tools auto-resolve account via FIZZY_ACCOUNT env var or single-account auto-detection.

ParametersJSON Schema
NameRequiredDescriptionDefault
actionYesAction: get | set | list. Use 'get' to check current, 'set' to change, 'list' to see available.
account_slugNoAccount slug (required for set action).

TDQS

A4.5/5.0
Behavior4/5

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

With no annotations, the description fully explains behavior: it describes each action's return format and side effects (setting the default). It reveals that get returns null if unset and that account_slug is only needed for set. Missing details like error handling for invalid slugs prevent a 5.

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 well-structured with clear sections (When to use, Arguments, Returns, Related). While slightly verbose, every sentence adds useful information. It could be more terse, but the clarity compensates.

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?

The description covers usage, behavior for all three actions, return formats, and related tools. It is comprehensive for a simple account management tool. Minor omission: no mention of error behavior for invalid slugs, but overall sufficient.

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?

The schema already covers the enum for action and provides descriptions. The description adds value by clarifying the conditional requirement of account_slug (required for set) and giving an example slug, going beyond the schema's 'required': ['action'] alone.

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 'Get, set, or list accounts for API calls' and explains it manages the session default. It distinguishes itself from sibling tools like fizzy_boards or fizzy_task by focusing solely on account context.

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?

The 'When to use' and 'Don't use' sections provide explicit guidance for when to use this tool (list, set, check) and when to avoid it (multi-account operations, suggesting explicit account_slug instead). It also references auto-resolution via env var, giving clear context for alternatives.

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

fizzy_boardsA

List boards in the account with column summaries.

Get an overview of boards and their column structure including card counts.

When to use:

  • Discover board IDs and column IDs for subsequent operations

  • See card counts per column across all boards

  • Find the right board/column to create cards or triage

Fizzy column conventions: Every board has three implicit columns not returned in the columns array:

  • Maybe? (inbox): Untriaged cards. Cards here have no column_id. New cards start here.

  • Not Now: Deferred cards. Move here via status: "not_now" in fizzy_task.

  • Done: Closed cards. Move here via status: "closed" in fizzy_task.

The columns array only contains custom workflow columns (e.g., "In Progress", "Backlog"). To move a card from a column back to Maybe?, use fizzy_task with column_id omitted and no status change.

Arguments:

  • account_slug (optional): Uses session default if omitted

  • limit (optional): Max items to return, 1-100 (default: 25)

  • cursor (optional): Continuation cursor from previous response

Returns: JSON with items and pagination metadata.

{"items": [{"id": "board_1", "name": "Project", "columns": [{"id": "col_1", "name": "Backlog"}]}], "pagination": {...}}

Related: Use board ID with fizzy_task to create cards. Use column IDs for triage.

ParametersJSON Schema
NameRequiredDescriptionDefault
account_slugNoAccount slug. Uses session default if omitted.
limitYesMax items to return (1-100, default: 25).
cursorNoContinuation cursor from previous response. Omit to start fresh.

TDQS

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. It discloses behavior beyond a simple list: explains implicit column conventions (Maybe?, Not Now, Done) and how columns array works. This is valuable for correct usage.

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?

Description is well-structured with clear sections: purpose, when to use, conventions, arguments, return format, related tools. Every sentence is meaningful and front-loaded with main purpose.

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?

Given no output schema, the description provides an example return JSON and explains pagination. The implicit column rule is critical for downstream operations, and the 'Related' section ties to sibling tools. Complete for a list tool.

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 has 100% coverage, but description adds significant meaning: explains account_slug default behavior, limit default range, cursor pagination usage, and column array contents. These details compensate fully.

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 starts with a clear verb+resource: 'List boards in the account with column summaries.' It distinguishes from sibling tools like fizzy_task (create cards) and fizzy_search by focusing on board listing and column discovery.

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?

The 'When to use' section explicitly states purposes: discover board IDs/column IDs, see card counts, find right board/column. It also relates to siblings via 'Related' line. Missing explicit 'when not to use', but context is clear.

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

fizzy_commentA

Manage comments on a card: create, list, update, or delete.

Actions:

  • create (default): Post a new comment

  • list: Get all comments on a card

  • update: Edit an existing comment (requires comment_id + body)

  • delete: Remove a comment (requires comment_id)

Arguments:

  • action (optional): "create" | "list" | "update" | "delete" (default: "create")

  • account_slug (optional): Uses session default if omitted

  • card_number (required): Card number

  • comment_id (optional): Required for update/delete

  • body (optional): Comment body in markdown. Required for create/update

Returns: JSON with comment details, list of comments, or deletion confirmation.

ParametersJSON Schema
NameRequiredDescriptionDefault
actionYesAction to perform.create
account_slugNoAccount slug. Uses default if omitted.
card_numberYesCard number.
comment_idNoComment ID. Required for update/delete.
bodyNoComment body in markdown (1-10000 chars). Required for create/update.

TDQS

A4.3/5.0
Behavior4/5

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

The description discloses all four actions and their effects, including deletion which is destructive. Without annotations, the description carries the full burden and covers behavior well. It doesn't mention auth needs or rate limits, but returns are described.

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 well-structured with sections for actions and arguments, using markdown for readability. It conveys necessary info without extraneous text, though slightly verbose. Still efficient.

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?

Given no output schema, the description mentions return types (comment details, list, confirmation), completing the picture. It covers all actions and parameter requirements. Could specify exact JSON fields, but sufficient for an agent.

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%, but the description adds value by grouping parameters by action and clarifying defaults (e.g., 'Uses session default if omitted' for account_slug). It also specifies markdown format for body, complementing 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 it manages comments on a card with four actions (create, list, update, delete). The tool name 'fizzy_comment' and its relation to other Fizzy tools (account, boards, etc.) is distinct, providing a specific verb+resource.

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?

The description explicitly lists when each action is used and required arguments. While it doesn't contrast with sibling tools, the siblings have different purposes (account, boards, search), so the context is clear. It could mention not to use this tool for other card operations.

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

fizzy_get_cardA

Get full details of a card by its number or ID. Retrieve complete card data including description, steps count, and metadata.

When to use:

  • Need full description or metadata for a specific card

  • Check step completion status or see all tags/assignees

Don't use when: Scanning multiple cards - use fizzy_search first.

Arguments:

  • account_slug (optional): Uses session default if omitted

  • card_number (recommended): The human-readable # number from URLs/lists (e.g., 42)

  • card_id (alternative): The UUID from API responses. Use card_number when possible.

IMPORTANT: Provide card_number (integer) OR card_id (string UUID), not both. The card_number is the # visible in the UI (e.g., #42). The card_id is the internal UUID.

Returns: JSON with id, number, title, description (markdown), status, board_id, column_id, tags array, assignees array, steps_count, completed_steps_count, comments_count, url, created_at, updated_at, closed_at (null if open). Example: {"id": "card_abc", "number": 42, "title": "Fix bug", "status": "open", "steps_count": 3, ...}

Related: Use fizzy_comment or fizzy_step for deeper interaction.

ParametersJSON Schema
NameRequiredDescriptionDefault
account_slugNoAccount slug (e.g., 'acme-corp'). Uses session default if omitted.
card_numberNoCard number - the human-readable # from URLs/UI (e.g., 42). Preferred over card_id.
card_idNoCard UUID from API responses. Use card_number instead when you have the # visible in the UI.

TDQS

A4.8/5.0
Behavior4/5

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

The description explains what the tool returns in detail (JSON fields with examples) and clarifies the two identification methods. It implies a read-only operation but does not explicitly state that. Given no annotations, the description carries the burden adequately, though it could explicitly mention read-only behavior.

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 well-structured with clear sections: purpose, when to use, arguments, important notes, and return format. It is concise with no redundant information, making it easy for an agent to parse.

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?

The description covers all necessary aspects: purpose, input parameters with guidance, output format with example, and related tools. For a simple get tool, this is complete and leaves no ambiguity.

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%, but the description adds significant value: explains the meaning of card_number (UI #) vs card_id (API UUID), provides preferred usage, and includes example values. This greatly enhances usability beyond the schema descriptions.

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 'Get full details of a card by its number or ID.' It distinguishes the tool from sibling search tool by specifying it retrieves complete card data for a single card, and mentions related tools for deeper interaction.

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 states when to use (need full description/metadata) and when not to use (scanning multiple cards - use fizzy_search). Provides clear context for usage and references alternatives.

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

fizzy_stepA

Create, complete, update, uncomplete, or delete a step on a card.

Mode detection:

  • step absent → CREATE (requires content)

  • step present, no other params → COMPLETE (default action)

  • step + content → UPDATE content

  • step + completed: false → UNCOMPLETE

  • step + delete: true → DELETE

Arguments:

  • account_slug (optional): Uses session default if omitted

  • card_number (required): Card number containing the step

  • step (optional): Content substring to match OR 1-based index to identify existing step

  • content (optional): Step text for create or update

  • completed (optional): Set completion state (true or false)

  • delete (optional): Delete the step

Returns: JSON with step id, content, completed status.

Examples:

  • Create: {card_number: 42, content: "Write tests"}

  • Complete: {card_number: 42, step: "Write tests"}

  • Uncomplete: {card_number: 42, step: 1, completed: false}

  • Update: {card_number: 42, step: 1, content: "Write unit tests"}

  • Delete: {card_number: 42, step: "Write tests", delete: true}

ParametersJSON Schema
NameRequiredDescriptionDefault
account_slugNoAccount slug. Uses default if omitted.
card_numberYesCard number containing the step.
stepNoStep to act on: content substring or 1-based index. Omit to create.
contentNoStep text for create or update.
completedNoSet completion state.
deleteNoDelete the step.

TDQS

A4.6/5.0
Behavior5/5

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

With no annotations provided, the description fully discloses behavior: it explains modes, parameter interactions, optionality, and return format. There are no contradictions, and the agent understands side effects (e.g., deletion is described).

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 well-structured with headings and bullet points, front-loading the purpose. It is somewhat lengthy due to comprehensive coverage, but every sentence adds value; minor trimming could improve conciseness.

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?

Given 6 parameters (1 required), no output schema, and no annotations, the description is thorough: it covers all modes, parameter semantics, and return values. An agent can use this tool correctly without additional context.

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 baseline is 3. The description adds substantial value beyond the schema by explaining the mode detection logic, how 'step' can be a substring or index, and how parameters combine. This aids correct invocation.

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 the tool's purpose: 'Create, complete, update, uncomplete, or delete a step on a card.' It uses specific verbs and a resource (step on a card), and the sibling tool names (e.g., fizzy_boards, fizzy_get_card) confirm it is distinct.

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?

The description provides explicit mode detection logic and examples for each action, guiding when to use which parameters. It does not explicitly contrast with siblings, but the sibling names and context make the tool's domain clear.

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

fizzy_taskA

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"]}

ParametersJSON 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).

TDQS

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
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A4.5/5.0
Disambiguation5/5

Each tool has a clearly distinct purpose with minimal overlap. For example, fizzy_get_card retrieves a single card's details, fizzy_search finds multiple cards with filters, and fizzy_task creates/updates cards, while fizzy_step and fizzy_comment manage sub-resources. The descriptions clearly differentiate when to use each tool, preventing misselection.

Naming Consistency5/5

All tool names follow a consistent 'fizzy_' prefix with descriptive noun suffixes (e.g., account, boards, comment, get_card, search, step, task). This uniform snake_case pattern makes the tool set predictable and easy to understand, with no deviations in naming conventions.

Tool Count5/5

With 7 tools, the set is well-scoped for a task/project management domain. It covers core operations like account management, board listing, card retrieval, search, creation/updates, and sub-resource handling (steps, comments), which is appropriate without being overly sparse or bloated.

Completeness5/5

The tool set provides comprehensive coverage for managing tasks in Fizzy, including CRUD operations for cards (via fizzy_task and fizzy_get_card), searching (fizzy_search), board exploration (fizzy_boards), and handling steps and comments. It also includes account management (fizzy_account), ensuring no obvious gaps for typical workflows.

Maintenance

ActivityInactive
ResponsivenessSyncing

Resources

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

Related MCP Servers

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