Skip to main content
Glama
Vuxified

Podio MCP Server

by Vuxified
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Hybrid

Create Item

podio_create_item

Create a new item in a Podio app by mapping field IDs to values, with automatic duplicate detection to reuse existing items instead of adding duplicate records.

Instructions

Creates a new item in a Podio app. The fields object maps field external_ids (or field_ids) to values. IMPORTANT: Call podio_get_app first to learn field types and option IDs. Field format varies by type: text='string', number=42, date={start:'YYYY-MM-DD'}, category=option_id (integer from app field settings), money={value:100,currency:'USD'}, app_reference=[item_id_1, item_id_2] (array of integer item IDs).

DUPLICATE DETECTION: Before creating, this tool automatically searches for potential duplicates using text field values. If duplicates are found, the item is NOT created — instead, the matches are returned with their item_ids. You MUST automatically use the existing item_ids from the matches instead of creating new items. Only use skip_duplicate_check=true if the user explicitly says to create a new/separate record despite the duplicate.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
tagsNoOptional tags to apply to the item
app_idYesApp ID to create the item in
fieldsYesField values keyed by external_id or field_id. Use podio_get_app to learn field types and option IDs. Examples: text='string', number=42, date={start:'2026-04-01'}, category=option_id, money={value:100,currency:'USD'}
silentNoIf true, no notifications are generated (default: false)
skip_duplicate_checkNoIf true, skip duplicate detection and create immediately (default: false)

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.0.0

TDQS

A4.4/5.0
Behavior4/5

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

With no annotations, the description carries the full burden and discloses important behavior: automatic duplicate detection, that matches block creation, and how to force creation via skip_duplicate_check. It does not disclose permissions required, success response shape, or other mutation side effects beyond duplicate handling.

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 front-loaded with purpose and well organized into field-format and duplicate-detection blocks. Some field examples duplicate the schema almost verbatim, so it is slightly longer than strictly necessary, but the content is useful for a nested fields object.

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?

For a nested, mutation-oriented tool with no annotations and no output schema, the description is largely complete: it explains field formatting, the get_app prerequisite, and duplicate behavior. It leaves gaps around success return values and permission/auth requirements, which are relevant because no annotations or output schema cover them.

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?

Although schema coverage is already 100%, the description adds meaningful field-value semantics beyond the schema, including app_reference as an array of integer item IDs and the need to fetch app field settings before supplying category option IDs. The duplicate-check guidance also clarifies the behavior of skip_duplicate_check beyond its schema description.

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 states a specific verb and resource: "Creates a new item in a Podio app." This clearly distinguishes creation from sibling operations such as podio_update_item, podio_get_item, and podio_delete_item.

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?

It gives strong prerequisites and conditional behavior: call podio_get_app first to learn field types, and do not create when duplicates are found unless skip_duplicate_check is explicitly justified. It does not explicitly name podio_update_item as the alternative for modifying an existing record, which keeps it from a 5.

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

Deploy Server

Other Tools