AIsa Sales

Bulk Create Tasks

post_apollo_tasks_bulk_create

Destructive

Bulk create tasks. 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_ids": {
+      "description": "The Apollo IDs for the contacts that you want to be on the receiving end of the action. <br><br>If you add multiple contact IDs, individual tasks will be created for each of the contacts using the same task type, due date, and other details. <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`",
+      "items": {
+        "type": "string"
+      },
+      "type": "array"
+    },
+    "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"
+    },
+    "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 contacts. </li> <li> `outreach_manual_email`: Email the contacts. </li> <li> `linkedin_step_connect`: Send a LinkedIn invitation to connect with the contacts. </li> <li> `linkedin_step_message`: Send a direct message to the contacts' LinkedIn profiles. </li> <li> `linkedin_step_view_profile`: View the contacts' LinkedIn profiles. </li> <li> `linkedin_step_interact_post`: Interact with the contacts' recent LinkedIn posts. </li> <li> `action_item`: Take generic action for the contacts. 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_ids",
+    "type",
+    "status",
+    "due_at"
+  ],
+  "type": "object"
+}

removedInput schema / properties / contact_ids

Removed value: -{
-  "description": "Contact IDs.",
-  "items": {
-    "type": "string"
-  },
-  "type": "array"
-}

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_ids",
-  "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 destructiveHint=true, idempotentHint=false, openWorldHint=true and readOnlyHint=false, so the mutation/write nature is covered without the description. The description adds the master-key auth requirement, which is useful non-schema context. It says nothing about batch-size limits, partial-failure behavior, or reversibility of created tasks.

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 sentences, front-loaded with purpose then requirement, with no author-supplied padding. The trailing pricing comment is injected boilerplate rather than authored content, so it is not heavily penalized.

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 an output schema present, return values need no explanation and annotations cover the safety profile. What remains missing for a bulk mutation tool is whether the batch is atomic, any cap on contact_ids, and the auth scope consequence if the master key is absent — the description stops at naming the requirement.

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?

Measured schema description coverage is 0% at the parameter level (the sole top-level 'body' object is undocumented), and the description supplies no parameter information at all, so it fails to compensate. The nested properties do carry rich inline descriptions (examples, ISO 8601 format, enum values), which keeps this from being a 1, but the description itself contributes nothing.

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?

States a specific verb and resource ('Bulk create tasks'), and the 'Bulk' qualifier implicitly separates it from the single-create sibling post_apollo_tasks. It does not name any sibling explicitly, so it lands at clear-but-not-differentiated.

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?

The prerequisite 'Requires a master API key' is a genuine usage condition, which is more than most. However, there is no guidance on when to prefer this over post_apollo_tasks or post_apollo_tasks_search, so the when-to-use dimension is only implied by the tool name.

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?