Skip to main content
Glama
ignytehq

plunk-mcp

Official
by ignytehq
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

Create contact

plunk_create_contact
Idempotent

Add a single contact or update an existing one by email. Safe to call twice, ensuring the contact exists before acting on them.

Instructions

Purpose: Create a contact, or update it if the email already exists. Safe to call twice.

Not for: Adding many at once, which is plunk_import_contacts.

Returns: The created or updated contact.

Use when: Adding a single person, or ensuring one exists before acting on them.

Note: Emails are normalised server-side for case and whitespace on Plunk v0.12+.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
dataNoCustom contact fields, e.g. {plan: 'pro'}
emailYes
subscribedNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed3 schema fields changedv2.0.0
    • addedInput schema / $schema
      Added value: +"https://json-schema.org/draft/2020-12/schema"
    • removedInput schema / additionalProperties
      Removed value: -false
    • addedInput schema / properties / data / propertyNames
      Added value: +{
+  "type": "string"
+}
  2. First observedv1.2.0

TDQS

A4.4/5.0
Behavior4/5

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

Annotations already declare idempotentHint=true, destructiveHint=false and openWorldHint=true, so 'safe to call twice' largely restates structured data. The description still earns credit for genuinely new behavior: the upsert on existing email and server-side email normalization (case/whitespace) on Plunk v0.12+.

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?

Five short labeled lines, front-loaded with Purpose and Not-for, then Returns, Use-when and Note. Every sentence carries information an agent needs; no padding.

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?

With no output schema, the description usefully states the return value ('the created or updated contact'), and it covers the upsert, the bulk alternative and normalization. The only remaining gap is semantics for the nested `data` object and the `subscribed` flag.

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?

Schema coverage is only 33%: only `data` has a description (with an example), while `email` and `subscribed` are undocumented. The description adds real meaning for `email` via the normalization note, but leaves `subscribed` and the custom-field semantics of `data` unexplained, so it only partially compensates for the coverage gap.

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 (create a contact) plus the critical upsert behavior — it updates when the email already exists. It also names the sibling it is not (plunk_import_contacts), so an agent can route correctly without opening any schema.

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?

Explicit 'Not for' clause names the alternative tool for bulk creation, and 'Use when' states both selecting conditions (adding a single person, or ensuring one exists before acting on them). Nothing is left to inference.

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