AIsa Sales

View or Update Deal

patch_apollo_opportunities_opportunity_id

Destructive

View a deal (opportunity) by ID. 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
`opportunity_id`	Yes	Opportunity ID

Output Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

Changed9 schema fields changedOct 19, 2026

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

removedInput schema / properties / amount

Removed value: -{
-  "description": "Amount",
-  "type": "number"
-}

addedInput schema / properties / body

Added value: +{
+  "properties": {
+    "amount": {
+      "description": "The monetary value of the deal. Enter a different value to update the deal amount. <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": "Update 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": "Update the name of the deal. 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. Enter a different ID to update the deal stage. <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. Enter a different ID to update the owner of the deal. <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"
+    }
+  },
+  "type": "object"
+}

removedInput schema / properties / closed_date

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

removedInput schema / properties / name

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

removedInput schema / properties / opportunity_stage_id

Removed value: -{
-  "description": "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: -[
-  "opportunity_id"
-]New value: +[
+  "opportunity_id",
+  "body"
+]

First observedSep 15, 2026

TDQS

D1.6/5.0

Behavior1/5

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

The annotations declare readOnlyHint=false and destructiveHint=true, but the description says 'View a deal', implying a read-only operation. This contradicts the mutation/destructive nature of the tool and omits what fields are updated, whether changes are reversible, or what gets destroyed.

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?

The description is short and front-loads a functional statement, but that statement is the wrong operation for the tool and is followed by pricing boilerplate rather than necessary update guidance.

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

Completeness1/5

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

For a destructive PATCH tool with annotations, nested body parameters, and a required body object, the description is critically incomplete. It omits update semantics entirely and instead describes a read operation, leaving an agent unable to safely invoke the tool from the description alone.

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 50%, and the description adds almost no parameter meaning beyond 'by ID'. It does not explain the required body object or any of the update fields, leaving the schema to carry most of the semantic load.

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

Purpose2/5

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

The description names a resource and ID lookup ('View a deal (opportunity) by ID'), but the tool is a PATCH update tool. It gives the wrong core verb and fails to distinguish itself from the GET sibling get_apollo_opportunities_opportunity_id.

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

Usage Guidelines1/5

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

It only states an authentication prerequisite ('Requires a master API key') and provides no guidance on when to use this PATCH tool versus the GET tool or other update endpoints. The only usage signal it gives is misleading because it frames the operation as viewing rather than updating.

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?