AIsa Sales

Create a Task

post_apollo_tasks

Destructive

Create a task. Requires a master API key.

Published reference price: $0.012 USD per successful request. Account-specific pricing and final settlement may differ.

Input Schema

Name	Required	Description	Default
`body`	Yes

Output Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

Changed10 schema fields changedOct 19, 2026

addedInput schema / additionalProperties
```
Added value: +false
```

addedInput schema / properties / body

Added value: +{
+  "properties": {
+    "contact_id": {
+      "description": "The Apollo ID for the contact that you want to be on the receiving end of the action. <br><br>To find contact IDs, call the <a href=\"https://docs.apollo.io/reference/search-for-contacts\" target=\"_blank\">search for contacts endpoint</a> and identify the `id` value for the contact. <br><br>Example: `66e34b81740c50074e3d1bd4`",
+      "type": "string"
+    },
+    "due_at": {
+      "description": "The full date and time when the task will be due. <br><br>Your entry should adhere to the <a href=\"https://www.rfc-editor.org/rfc/rfc3339#section-5.6\" target=\"_blank\">ISO 8601 date-time format</a>. Apollo uses Greenwich Mean Time (GMT) by default. If you do not account for time zone differences, you could add a task due date that falls on a different day than you intended. <br><br>The value you enter can either adhere to GMT, or you can adjust the time manually by specifying in hours and minutes how much you want to offset GMT.<br><br>Example: `2025-02-15T08:10:30Z`; `2025-03-25T10:15:30+05:00`",
+      "format": "date-time",
+      "type": "string"
+    },
+    "note": {
+      "description": "Add a description for the task. This should be a human-readable message. <br><br>This parameter is not required, but it is recommended as it provides the task owner with more context on the action they need to take. <br><br>Example: `This contact expressed interest in the Sequences feature specifically. Be prepared to discuss.`",
+      "type": "string"
+    },
+    "priority": {
+      "default": "medium",
+      "description": "Assign a priority to the task you are creating: <ul> <li> `high` </li> <li> `medium` </li> <li> `low` </li> </ul>",
+      "type": "string"
+    },
+    "status": {
+      "description": "The status of the task being created. For future-facing tasks, you should use the `scheduled` status. <br><br>For tasks that are already completed, you can use `completed` or `skipped`. <br><br>Example: `scheduled`",
+      "type": "string"
+    },
+    "title": {
+      "description": "A title for the task. If omitted, Apollo will display an auto-generated title based on the task type and contact name. <br><br>Example: `Follow up on demo request`",
+      "type": "string"
+    },
+    "type": {
+      "description": "Set the task to be 1 of the following task types. This enables the task owner to know the type of action they need to take. <ul> <li> `call`: Call the contact. </li> <li> `outreach_manual_email`: Email the contact. </li> <li> `linkedin_step_connect`: Send a LinkedIn invitation to connect with the contact. </li> <li> `linkedin_step_message`: Send a direct message to the contact's LinkedIn profile. </li> <li> `linkedin_step_view_profile`: View the contact's LinkedIn profile. </li> <li> `linkedin_step_interact_post`: Interact with the contact's recent LinkedIn posts. </li> <li> `action_item`: Take generic action for the contact. If you use this task type, Apollo recommends using the `note` parameter too. </li> </ul>",
+      "type": "string"
+    },
+    "user_id": {
+      "description": "The ID for the task owner within your team's Apollo account. This is the user that will take action on the contacts. <br><br>Use the <a href=\"https://docs.apollo.io/reference/get-a-list-of-users\" target=\"_blank\">get a list of users endpoint</a> to retrieve IDs for all of the users within your Apollo account. <br><br>Example: `66302798d03b9601c7934ebf`",
+      "type": "string"
+    }
+  },
+  "required": [
+    "user_id",
+    "contact_id",
+    "type",
+    "status",
+    "due_at"
+  ],
+  "type": "object"
+}

removedInput schema / properties / contact_id

Removed value: -{
-  "description": "Contact ID.",
-  "type": "string"
-}

removedInput schema / properties / due_at

Removed value: -{
-  "description": "ISO 8601 due datetime.",
-  "type": "string"
-}

removedInput schema / properties / priority

Removed value: -{
-  "description": "Task priority (default: medium).",
-  "type": "string"
-}

removedInput schema / properties / status

Removed value: -{
-  "description": "Task status.",
-  "type": "string"
-}

removedInput schema / properties / title

Removed value: -{
-  "description": "Optional title.",
-  "type": "string"
-}

removedInput schema / properties / type

Removed value: -{
-  "description": "Task type.",
-  "type": "string"
-}

removedInput schema / properties / user_id

Removed value: -{
-  "description": "Task owner user ID.",
-  "type": "string"
-}

changedInput schema / required

Previous value: -[
-  "user_id",
-  "contact_id",
-  "type",
-  "status",
-  "due_at"
-]New value: +[
+  "body"
+]

First observedSep 15, 2026

TDQS

B3.2/5.0

Behavior3/5

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

Annotations already declare readOnlyHint=false, destructiveHint=true, openWorldHint=true, and idempotentHint=false, so the write/safety profile is covered. The description adds the master-API-key auth requirement, which is genuinely beyond the annotations, but says nothing about side effects (e.g. notifying the assigned user), error behavior on invalid user_id/contact_id, or why a create is flagged destructive.

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 two substantive sentences are front-loaded with the action verb and contain no filler. The trailing aisa-pricing block is injected boilerplate and does not dilute the definition. Brevity is appropriate, though it comes at the cost of the gaps noted elsewhere rather than from trimming genuine 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?

An output schema exists, so return values need not be explained, and annotations cover the safety profile. What remains missing for a mutation tool with a nested required body object is the wrapper-structure explanation, side effects on the assigned user, and any guidance on single vs. bulk creation. Adequate but clearly incomplete.

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 description coverage is 0%: the single top-level parameter 'body' has no description, and the tool description says nothing about parameters. It never explains that all task fields (user_id, contact_id, type, status, due_at, note, title, priority) must be nested inside a body object, which is the one non-obvious structural fact an agent needs. The nested property descriptions are rich, but that is the schema doing the work, not the description.

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 states a specific verb and resource: 'Create a task.' Combined with the title 'Create a Task' this is unambiguous about what the tool does. It does not, however, distinguish itself from the sibling post_apollo_tasks_bulk_create or explain how it relates to post_apollo_tasks_search, so sibling differentiation is left to the name.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

'Requires a master API key' gives one concrete prerequisite, which is more than most descriptions offer. There is no guidance on when to choose this over post_apollo_tasks_bulk_create, no note that this creates exactly one task, and no statement of when not to use it, so usage is only implied.

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

All AIsa Sales tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?