Skip to main content
Glama

Conecto CRM

Create a task

crm_create_task

A follow-up on a contact, with an optional due time (ISO 8601) and priority. Costs $0.01 per call; nothing if it fails.

Input Schema

NameRequiredDescriptionDefault
emailNo
titleYes
due_atNoISO 8601, e.g. 2026-10-20T09:00:00Z
detailsNo
priorityNo
contact_idNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

C2.8/5.0
Behavior4/5

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

The description adds genuinely useful context beyond the annotations: the $0.01 per-call cost and that failures are not billed. That is real behavioral information an agent can't get from readOnlyHint/destructiveHint/idempotentHint alone, though linkage requirements between email and contact_id remain undisclosed.

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?

One short sentence with no padding, but it is a noun phrase rather than a front-loaded statement of what the call does. It is concise at the cost of being under-specified.

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?

For a 6-parameter mutation with 17% schema coverage and no output schema, the description omits how a task is attached to a record (email vs contact_id), whether title-only calls are valid, and what is returned. Only the billing and priority/due_at notes are covered.

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

Parameters2/5

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

Schema coverage is only 17% across 6 parameters, so the description must compensate and does not. It restates due_at/priority (already in schema, including the enum) but says nothing about the crucial email vs contact_id choice or what details is for.

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

Purpose3/5

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

The description names the resource ('a follow-up on a contact') and two of its fields, so an agent can infer this creates a task, but it never states the action verb — the verb only appears in the title. It also doesn't distinguish itself from siblings like tasks_create or crm_add_note.

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 guidance on when to use this versus tasks_create, crm_complete_task, or crm_add_note, nor any prerequisite or exclusion stated. The agent must infer usage entirely from the name.

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.

Resources