Skip to main content
Glama

Keap MCP by usefulapi

Create task

keap_create_task
Destructive

CREATE a task (follow-up / to-do), optionally linked to a contact. Keap: POST /tasks.

Input Schema

NameRequiredDescriptionDefault
extraNoAny other Keap fields to merge into the request body verbatim.
titleYesThe task title.
due_dateNoDue date/time, ISO 8601 (e.g. 2026-08-01T17:00:00Z).
contact_idNoId of a contact to link the task to.
descriptionNoA longer description / notes for the task.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • changedInput schema / $schema
      Previous value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"
  2. First observed

TDQS

C2.9/5.0
Behavior2/5

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

Annotations already declare destructiveHint=true, and the description adds only the raw endpoint (POST /tasks). It does not say whether the task is auto-assigned to a user, whether reminders/notifications fire, what permissions are needed, or what a caller gets back. For a write operation with a destructive hint, this leaves real behavioral gaps.

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?

Two short, front-loaded sentences with no filler; the action and scope come first and the endpoint reference is a compact footnote. Nothing redundant, though the endpoint line is marginal value.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With 5 parameters, a nested passthrough object, no output schema, and only a destructiveHint annotation, the description is thin but the schema carries the field-level detail. It omits side effects, permissions, and any mention of the 'extra' passthrough, which an agent might need for non-standard Keap fields.

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 description coverage is 100%, so the baseline is 3. The description adds only the optionality of contact linkage and the follow-up/to-do framing, but says nothing about the 'extra' verbatim merge object or due-date expectations.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description gives a specific verb+resource ('CREATE a task') and clarifies scope with 'follow-up / to-do, optionally linked to a contact,' which separates it from keap_get_task and keap_list_tasks. It is clear but does not explicitly name those siblings as the alternatives.

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?

There is no statement of when to use this versus keap_update_contact, keap_apply_tag, or keap_list_tasks, and no prerequisites or exclusions are given. The only implied guidance is the optional contact linkage.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.