AIsa Sales

Create Deal

post_apollo_opportunities

Destructive

Create a deal (opportunity). 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
```

removedInput schema / properties / account_id

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

removedInput schema / properties / amount

Removed value: -{
-  "description": "Deal amount",
-  "type": "number"
-}

addedInput schema / properties / body

Added value: +{
+  "properties": {
+    "account_id": {
+      "description": "The ID for the account within your Apollo instance. This is the company that you are targeting as part of the deal being created. <br><br>Each company in the Apollo database is assigned a unique ID. To find IDs, call the <a href=\"https://docs.apollo.io/reference/organization-search\" target=\"_blank\">organization search endpoint</a> and identify the values for `organization_id`. <br><br>Example: `5e66b6381e05b4008c8331b8`",
+      "type": "string"
+    },
+    "amount": {
+      "description": "The monetary value of the deal being created. <br><br>Do not enter commas or currency symbols for the value. The currency is automatically populated by the settings within your Apollo account. Commas are not accepted and result in the deal amount being left blank. <br><br>Example: `55123478` (results in a deal value of `$55,123,478` if the default currency is USD)",
+      "type": "string"
+    },
+    "closed_date": {
+      "description": "The estimated close date for the deal. This can be a future or past date. <br><br>The date should be formatted as `YYYY-MM-DD`. <br><br>Example: `2025-10-30`",
+      "format": "date",
+      "type": "string"
+    },
+    "name": {
+      "description": "Name the deal you are creating. This should be a human-readable name. <br><br>Example: `Massive Q3 Deal`",
+      "type": "string"
+    },
+    "opportunity_stage_id": {
+      "description": "The ID for the deal stage within your team's Apollo account. <br><br>Each deal stage is assigned a unique ID. To find deal stage IDs, call the <a href=\"https://docs.apollo.io/reference/list-deal-stages\" target=\"_blank\">list deal stages endpoint</a> and identify the value for `id` for each stage. <br><br>Example: `6095a710bd01d100a506d4bd`",
+      "type": "string"
+    },
+    "owner_id": {
+      "description": "The ID for the deal owner within your team's Apollo account. <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"
+    },
+    "typed_custom_fields": {
+      "additionalProperties": {
+        "type": "string"
+      },
+      "description": "Add information to <a href=\"https://knowledge.apollo.io/hc/en-us/articles/4415062486669-Create-a-Deal\" target=\"_blank\">custom fields</a> in Apollo. <br><br><b>Your custom fields are unique to your team's Apollo account. This means that the examples in this documentation may not work for your testing purposes.</b> <br><br>To utilize this parameter successfully, call the <a href=\"https://docs.apollo.io/reference/get-a-list-of-all-custom-fields\">get a list of all custom fields</a> endpoint and identify the `id` value for the custom field, as well as the appropriate data type. For example, if a custom field accepts picklist entries, you need to pass the accompanying `id` value for the picklist entry that you want to use as the input value. <br><br><b>Example</b>: When the <a href=\"https://docs.apollo.io/reference/get-a-list-of-all-custom-fields\">get a list of all custom fields</a> endpoint returns an `id` of field: \n * `\"60c39ed82bd02f01154c470a\"` (datetime) \n \n\n then the value passed should be: \n\n `{\"60c39ed82bd02f01154c470a\": \"2025-08-07\"}`",
+      "example": {
+        "60c39ed82bd02f01154c470a": "2025-08-07"
+      },
+      "type": "object"
+    }
+  },
+  "required": [
+    "name"
+  ],
+  "type": "object"
+}

removedInput schema / properties / closed_date

Removed value: -{
-  "description": "Closed date (date string)",
-  "type": "string"
-}

removedInput schema / properties / name

Removed value: -{
-  "description": "Deal name",
-  "type": "string"
-}

removedInput schema / properties / opportunity_stage_id

Removed value: -{
-  "description": "Deal stage ID",
-  "type": "string"
-}

removedInput schema / properties / owner_id

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

removedInput schema / properties / typed_custom_fields

Removed value: -{
-  "description": "Typed custom fields object",
-  "type": "object"
-}

changedInput schema / required

Previous value: -[
-  "name"
-]New value: +[
+  "body"
+]

First observedSep 15, 2026

TDQS

B3/5.0

Behavior3/5

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

Annotations already declare readOnlyHint=false, destructiveHint=true, idempotentHint=false and openWorldHint=true, so the mutation profile is covered. The description adds the auth requirement (master API key), which annotations do not convey, but says nothing about creation side effects, duplicate handling, or required related entities.

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 the action and followed by the key precondition, with no wasted prose. The injected pricing comment block is boilerplate noise rather than description content.

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?

A mutation tool with a required nested body object and no annotation-level detail about creation semantics; an output schema exists so return values need not be explained. The description covers only the action and auth, leaving the agent to infer prerequisite IDs and creation behavior entirely from the nested schema.

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?

Top-level schema description coverage is 0% (the single 'body' parameter is undescribed), and the description contributes no parameter meaning at all. The nested body properties are in fact richly documented in the schema, which limits the damage, but the description itself does nothing to compensate for the coverage gap.

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 deal (opportunity)') and usefully disambiguates the API's 'opportunity' terminology as a 'deal'. It does not differentiate itself from siblings like patch_apollo_opportunities or get_apollo_opportunities_search, but the create action is unmistakable.

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?

The only guidance is an authentication prerequisite ('Requires a master API key'), which is a precondition rather than a when-to-use rule. There is no mention of when to create a deal versus updating one, or of what pre-existing entities (stage, account, owner) must be resolved first.

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?