Skip to main content
Glama

Create Kanban Card

basecamp_create_kanban_card

Create a new kanban card in a specified column, with optional checklist steps, assignees, and due dates.

Instructions

Create a new card in a kanban column with optional checklist steps.

HTML rules for content:

  • Allowed tags: p, span, h2, h3, h4, br, strong, em, strike, code, a (with href attribute), pre, ol, ul, li, blockquote, mark, figure, figcaption, table, tbody, tr, th, td, div, bc-attachment.

  • Use for paragraphs. Use for empty line spacing between paragraphs.

  • Headings: use , , as appropriate.

  • Inline code: text. Preformatted blocks: text.

  • Ordered lists: .... Unordered: ....

  • Tables: Heading...Cell...

  • To mention people:

  • Single image:

  • Image gallery: wrap multiple in a .

  • Basecamp auto-enriches bc-attachment tags after saving (adds url, href, filename, content-type, etc.) — you never need to write those.

  • When you see an existing, already-enriched tag (e.g. from a previous list/get call), leave its inner HTML alone. Before any content_append/content_prepend/search_replace runs, it is automatically collapsed back to its minimal form (sgid, presentation, caption, and content-type for mentions) — you don't need to strip it yourself, and doing so manually is unnecessary and risks mismatched find strings.

  • Background highlights: ...

  • Text color highlights: ...

  • For both, N is 1 (yellow), 2 (amber), 3 (red), 4 (pink), 5 (purple), 6 (blue), 7 (teal), 8 (near-white), or 9 (light gray).

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
stepsNoArray of steps to create. Array order defines position.
titleYes
due_onNoDue date in YYYY-MM-DD format
notifyNoWhether to notify assignees
contentNo
column_idYesBasecamp resource identifier
assignee_idsNoArray of user IDs to assign to the card

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed9 schema fields changedv1.2.1
    • addedInput schema / properties / assignee_ids / items / $ref
      Added value: +"#/properties/column_id"
    • removedInput schema / properties / assignee_ids / items / type
      Removed value: -"number"
    • removedInput schema / properties / bucket_id
      Removed value: -{
      -  "description": "Basecamp resource identifier",
      -  "type": "number"
      -}
    • removedInput schema / properties / column_id / $ref
      Removed value: -"#/properties/bucket_id"
    • addedInput schema / properties / column_id / description
      Added value: +"Basecamp resource identifier"
    • addedInput schema / properties / column_id / type
      Added value: +"number"
    • addedInput schema / properties / steps / items / properties / assignee_ids / items / $ref
      Added value: +"#/properties/column_id"
    • removedInput schema / properties / steps / items / properties / assignee_ids / items / type
      Removed value: -"number"
    • changedInput schema / required
      Previous value: -[
      -  "bucket_id",
      -  "column_id",
      -  "title"
      -]New value: +[
      +  "column_id",
      +  "title"
      +]
  2. Changed6 schema fields changedv1.0.0
    • addedInput schema / $schema
      Added value: +"http://json-schema.org/draft-07/schema#"
    • addedInput schema / additionalProperties
      Added value: +false
    • addedInput schema / properties / assignee_ids
      Added value: +{
      +  "description": "Array of user IDs to assign to the card",
      +  "items": {
      +    "type": "number"
      +  },
      +  "type": "array"
      +}
    • addedInput schema / properties / due_on
      Added value: +{
      +  "description": "Due date in YYYY-MM-DD format",
      +  "type": "string"
      +}
    • addedInput schema / properties / notify
      Added value: +{
      +  "description": "Whether to notify assignees",
      +  "type": "boolean"
      +}
    • addedInput schema / properties / steps
      Added value: +{
      +  "description": "Array of steps to create. Array order defines position.",
      +  "items": {
      +    "additionalProperties": false,
      +    "properties": {
      +      "assignee_ids": {
      +        "description": "Array of user IDs to assign",
      +        "items": {
      +          "type": "number"
      +        },
      +        "type": "array"
      +      },
      +      "completed": {
      +        "description": "Whether step is completed",
      +        "type": "boolean"
      +      },
      +      "due_on": {
      +        "description": "Due date (YYYY-MM-DD) or null",
      +        "type": [
      +          "string",
      +          "null"
      +        ]
      +      },
      +      "title": {
      +        "description": "Step title",
      +        "type": "string"
      +      }
      +    },
      +    "required": [
      +      "title"
      +    ],
      +    "type": "object"
      +  },
      +  "type": "array"
      +}
  3. First observed

TDQS

B3/5.0
Behavior2/5

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

Annotations indicate readOnlyHint=false (write operation) and idempotentHint=false, but the description does not add behavioral context beyond that. It does not disclose potential side effects (e.g., notifications, card visibility), auth requirements, or what happens after creation. The extensive HTML rules relate solely to content formatting, not to tool behavior.

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 core purpose is in a single, front-loaded sentence, which is good. However, the description then dives into a lengthy, detailed HTML formatting guide that, while necessary for rich content, is verbose and may overwhelm the agent. The structure is organized with bullet points, but the length makes it less concise than ideal.

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?

The tool has 7 parameters, no output schema, and sparse annotations. The description does not explain the return value, error conditions, or prerequisites (e.g., a valid column_id, authentication state). It provides HTML rules for content but omits other operational details. For a write operation of this complexity, the description is incomplete.

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

Parameters3/5

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

The schema already covers 71% of parameters with descriptions. The description adds meaningful guidance for the 'content' parameter through the detailed HTML rules, which is valuable and goes beyond schema. However, it does not clarify semantics for parameters like title (no schema description) or column_id beyond the schema's 'Basecamp resource identifier'. Given the partial coverage, the description partially compensates but not 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 first sentence clearly states 'Create a new card in a kanban column with optional checklist steps.' This is a specific verb+resource and distinguishes it from siblings like create_todo or move_kanban_card. The tool name and title reinforce the purpose, making it unambiguous.

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?

The description provides no guidance on when to use this tool versus alternatives such as basecamp_create_todo or basecamp_create_message. It does not state prerequisites, exclusions, or conditions that would help an agent decide between similar create tools. The only hint is 'kanban column' in the first sentence, but no explicit direction is given.

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