# RevCent MCP Operation: `EditChargeback` This document explains the `EditChargeback` operation in depth so MCP clients can correctly update existing chargeback records in RevCent. This guide is operation-specific, but it also explains the broader purpose of editing chargebacks in RevCent: keeping chargeback details accurate, tracking representment status, reporting chargebacks fought/won/lost/not fought, supporting third-party chargeback management companies, and maintaining reliable customer-level chargeback history. Sources: - RevCent API/MCP schema for `EditChargeback` - RevCent API/MCP schema for `GetChargeback` - RevCent API/MCP schema for `CreateChargeback` - RevCent API/MCP schema for `CreateChargebackDocument` - RevCent Knowledge Base: [Chargebacks](https://kb.revcent.com/en/payments/credit-card/chargeback) - RevCent Knowledge Base: [Automated Chargeback Management](https://kb.revcent.com/payments/credit-card/automated-chargeback-management) - RevCent Knowledge Base: [Chargeback Documents](https://kb.revcent.com/en/tools/documents) --- ## Operation Summary `EditChargeback` edits the details of an existing chargeback using the required `chargeback_id`. A chargeback in RevCent represents a dispute tied to a prior credit card transaction. Editing the chargeback lets the business keep the dispute record accurate as new information becomes available. Common reasons to edit a chargeback: - Add or correct the chargeback amount. - Add or correct the ARN. - Add or correct the case number. - Add or correct the reason code. - Add third-party chargeback IDs. - Update chargeback date or received date. - Add or update metadata. - Mark representment as initiated. - Mark representment as completed. - Record representment outcome as `pending`, `won`, or `lost`. The most important edit use case is updating `representment`, because representment fields allow RevCent reporting to distinguish between chargebacks that were fought, won, lost, pending, or not fought. --- ## Required Field | Field | Type | Required | Description | |---|---:|---:|---| | `chargeback_id` | string | Yes | The 20-character chargeback ID to edit. | Minimal shape: ```json { "chargeback_id": "XXXXXXXXXXXXXXXXXXXX" } ``` A real edit should include at least one additional field to update. --- ## Editable Fields | Field | Type | Description | |---|---:|---| | `chargeback_id` | string | Required 20-character chargeback ID. | | `amount` | number | Chargeback amount. | | `arn` | string | Acquirer reference number, if applicable. | | `case_number` | string | Case number, if applicable. | | `reason_code` | string | Reason code, if applicable. | | `third_party_chargeback_id` | string | External chargeback ID from a third-party chargeback management company. | | `third_party_order_id` | string | External order ID from a third-party chargeback management company. | | `chargeback_date` | string/date-time | Date chargeback was created by issuer/customer, in ISO8601 format. | | `received_date` | string/date-time | Date chargeback was received by the merchant, in ISO8601 format. | | `representment` | object | Details about any attempt to fight the chargeback. | | `metadata` | array | Custom name/value metadata. | --- # Important Edit Limitations `EditChargeback` does not include fields for: ```text transaction_id gateway_transaction_id void_transaction third_party_integration_id ``` That means: - The originating transaction association is established when the chargeback is created. - `EditChargeback` is not used to change the original transaction linkage. - `EditChargeback` is not used to void/refund the transaction. - `EditChargeback` is not used to add the third-party integration ID itself. If the original chargeback was created against the wrong transaction, the MCP should not assume `EditChargeback` can fix that relationship. The correct remediation depends on the broader data situation and business policy. --- # Partial Edit Behavior `EditChargeback` should be treated as a partial update operation. MCP should only include fields that should be modified. Correct amount-only edit: ```json { "chargeback_id": "XXXXXXXXXXXXXXXXXXXX", "amount": 99.95 } ``` Correct case-number-only edit: ```json { "chargeback_id": "XXXXXXXXXXXXXXXXXXXX", "case_number": "CB-123456789" } ``` Correct representment-only edit: ```json { "chargeback_id": "XXXXXXXXXXXXXXXXXXXX", "representment": { "initiated": true, "initiated_date": "2026-05-30T10:00:00Z", "outcome": "pending" } } ``` Do not include fields unnecessarily. If a field is not being changed, omit it. --- # Why Editing Chargebacks Matters Chargeback data changes over time. At first, a business may only know: ```text chargeback amount case number chargeback date ``` Later, the business may receive: ```text reason code ARN third-party case ID evidence request status representment initiated date representment outcome ``` Editing the chargeback keeps RevCent as the complete system of record for chargeback monitoring, reporting, risk review, and customer history. Accurate chargeback edits help answer: ```text Which chargebacks were fought? Which chargebacks were not fought? Which chargebacks are pending? Which chargebacks were won? Which chargebacks were lost? Which customers have chargeback history? Which campaigns or products create chargeback risk? Which mitigation provider is performing well? ``` --- # Representment Is the Most Important Editable Object The `representment` object tracks whether the business attempted to fight the chargeback. Representment fields are critical for reporting because they let RevCent distinguish between: - Chargebacks not fought - Chargebacks fought and pending - Chargebacks fought and won - Chargebacks fought and lost - Chargebacks with completed representment - Chargebacks still awaiting outcome Without representment fields, reporting can only show that a chargeback exists. With representment fields, reporting can show what happened after the chargeback was received. --- ## `representment` Fields Shape: ```json "representment": { "initiated": true, "initiated_date": "2026-05-30T10:00:00Z", "completed": true, "completed_date": "2026-06-15T12:00:00Z", "outcome": "won" } ``` | Field | Type | Description | |---|---:|---| | `initiated` | boolean | Whether representment has been initiated. Read-only once set. | | `initiated_date` | string/date-time | Date representment was initiated. Read-only once set. | | `completed` | boolean | Whether representment has completed with an outcome. Requires `initiated` to be true or previously true. Read-only once set. | | `completed_date` | string/date-time | Date representment was completed with an outcome. Read-only once set. | | `outcome` | string enum | Final representment outcome. Requires initiated and completed to be true or previously true for final outcomes. | Allowed `outcome` values: ```text pending won lost ``` --- ## Read-Only-Once-Set Warning Several representment fields are described as read-only once set: ```text initiated initiated_date completed completed_date ``` MCP should treat these as high-importance fields. Do not casually set them. Do not guess dates. Do not set `completed` unless the representment has actually completed. Do not set final outcome `won` or `lost` unless the result is known. Once these fields are set, they may not be editable again. --- # Reporting Meaning of Representment Fields Representment fields are important because they directly support chargeback reporting. ## Not Fought A chargeback can be considered not fought when representment was never initiated. Reporting concept: ```text representment.initiated is false or absent ``` Meaning: ```text Chargeback was recorded, but no representment was initiated. ``` Use this to report: - Chargebacks not fought - Disputes accepted as losses - Disputes only recorded for history/reporting - Chargebacks pending a fight/no-fight decision --- ## Fought / Pending A chargeback can be considered fought and pending when representment has been initiated, but no final completed outcome has been recorded. Reporting concept: ```text representment.initiated = true AND representment.outcome = pending ``` or: ```text representment.initiated = true AND representment.completed is false or absent ``` Meaning: ```text The chargeback is being fought, but the result is not known yet. ``` --- ## Fought / Won A chargeback can be considered fought and won when representment completed with outcome `won`. Reporting concept: ```text representment.initiated = true AND representment.completed = true AND representment.outcome = won ``` Meaning: ```text The business fought the chargeback and won. ``` --- ## Fought / Lost A chargeback can be considered fought and lost when representment completed with outcome `lost`. Reporting concept: ```text representment.initiated = true AND representment.completed = true AND representment.outcome = lost ``` Meaning: ```text The business fought the chargeback and lost. ``` --- ## Representment Reporting Categories Useful reporting categories include: | Category | Example Logic | |---|---| | Not fought | `representment.initiated` false or absent. | | Fought pending | `initiated = true`, outcome pending or completed not true. | | Won | `initiated = true`, `completed = true`, `outcome = won`. | | Lost | `initiated = true`, `completed = true`, `outcome = lost`. | | Total fought | `initiated = true`. | | Win rate | Won / total completed representments. | | Loss rate | Lost / total completed representments. | | Pending rate | Fought pending / total fought. | | Fight rate | Total fought / total chargebacks. | These categories are why editing representment accurately matters. --- # Representment Lifecycle Examples ## 1. Mark Representment Initiated Use this when the chargeback is being fought and the representment process has begun. ```json { "chargeback_id": "XXXXXXXXXXXXXXXXXXXX", "representment": { "initiated": true, "initiated_date": "2026-05-30T10:00:00Z", "outcome": "pending" } } ``` Meaning: ```text This chargeback is being fought. The outcome is not known yet. ``` --- ## 2. Mark Representment Completed and Won Use this when the chargeback was fought and won. ```json { "chargeback_id": "XXXXXXXXXXXXXXXXXXXX", "representment": { "completed": true, "completed_date": "2026-06-15T12:00:00Z", "outcome": "won" } } ``` Meaning: ```text Representment is complete and the business won. ``` If the chargeback did not previously have `initiated = true`, include it if accurate: ```json { "chargeback_id": "XXXXXXXXXXXXXXXXXXXX", "representment": { "initiated": true, "initiated_date": "2026-05-30T10:00:00Z", "completed": true, "completed_date": "2026-06-15T12:00:00Z", "outcome": "won" } } ``` --- ## 3. Mark Representment Completed and Lost Use this when the chargeback was fought and lost. ```json { "chargeback_id": "XXXXXXXXXXXXXXXXXXXX", "representment": { "completed": true, "completed_date": "2026-06-15T12:00:00Z", "outcome": "lost" } } ``` If initiated was not previously set, include accurate initiated values: ```json { "chargeback_id": "XXXXXXXXXXXXXXXXXXXX", "representment": { "initiated": true, "initiated_date": "2026-05-30T10:00:00Z", "completed": true, "completed_date": "2026-06-15T12:00:00Z", "outcome": "lost" } } ``` --- ## 4. Do Not Mark a Chargeback as Fought If the chargeback is only being tracked and was not fought, do not set `representment.initiated` to true. Example edit to add a reason code only: ```json { "chargeback_id": "XXXXXXXXXXXXXXXXXXXX", "reason_code": "13.1" } ``` Reporting can then treat this as not fought if representment remains absent or not initiated. --- # Editable Chargeback Detail Fields ## `amount` The chargeback amount. Example: ```json { "chargeback_id": "XXXXXXXXXXXXXXXXXXXX", "amount": 99.95 } ``` Guidance: - Use the amount from the chargeback notice, gateway, processor, or third-party provider. - Do not guess. - Use the disputed amount. - It may differ from the original transaction amount if the dispute is partial. --- ## `arn` The acquirer reference number, if applicable. Example: ```json { "chargeback_id": "XXXXXXXXXXXXXXXXXXXX", "arn": "12345678901234567890123" } ``` Use when supplied by the issuer, gateway, processor, acquirer, or chargeback management company. ARN is useful for reconciliation across systems. --- ## `case_number` The chargeback case number, if applicable. Example: ```json { "chargeback_id": "XXXXXXXXXXXXXXXXXXXX", "case_number": "CB-123456789" } ``` Use to track the case across: - Gateway - Processor - Issuer - Chargeback mitigation company - Internal support/risk workflows --- ## `reason_code` The chargeback reason code, if applicable. Example: ```json { "chargeback_id": "XXXXXXXXXXXXXXXXXXXX", "reason_code": "13.1" } ``` Guidance: - Do not invent reason codes. - Use the reason code supplied by the issuer, processor, gateway, card network, or chargeback management provider. - Reason codes are important for reporting and representment strategy. Reason-code reporting can help identify: - Product-not-received disputes - Fraud disputes - Subscription or billing confusion - Refund-related disputes - Product-not-as-described disputes - Duplicate-charge disputes - Authorization disputes --- ## `third_party_chargeback_id` The third-party integration chargeback ID. Example: ```json { "chargeback_id": "XXXXXXXXXXXXXXXXXXXX", "third_party_chargeback_id": "external_cb_123456" } ``` Use when a chargeback mitigation company or external provider has its own chargeback identifier. This helps reconcile RevCent chargebacks with the external case system. --- ## `third_party_order_id` The third-party integration order ID. Example: ```json { "chargeback_id": "XXXXXXXXXXXXXXXXXXXX", "third_party_order_id": "external_order_987654" } ``` Use when the third-party provider has its own order identifier. This helps connect: ```text RevCent chargeback ↔ external chargeback case ↔ external order ↔ originating sale/transaction ``` --- ## `chargeback_date` The date when the chargeback was created by the issuer and/or customer. Format: ```text ISO8601 date-time ``` Example: ```json { "chargeback_id": "XXXXXXXXXXXXXXXXXXXX", "chargeback_date": "2026-05-28T14:30:00Z" } ``` Use for: - Reporting by dispute creation date - Chargeback aging - Reason-code analysis by date - Monthly dispute reporting --- ## `received_date` The date when the chargeback was received by the merchant. Format: ```text ISO8601 date-time ``` Example: ```json { "chargeback_id": "XXXXXXXXXXXXXXXXXXXX", "received_date": "2026-05-29T09:00:00Z" } ``` Use for: - Internal operational queues - Chargeback handling timelines - SLA tracking - Evidence submission workflows - Third-party chargeback management workflows --- # Metadata `metadata` is an array of custom name/value pairs. Shape: ```json "metadata": [ { "name": "risk_review_status", "value": "pending" } ] ``` Each object requires: ```text name value ``` Use metadata for custom business or third-party context. Examples: ```json [ { "name": "chargeback_source", "value": "midigator" }, { "name": "external_case_status", "value": "evidence_submitted" }, { "name": "risk_review_status", "value": "pending" }, { "name": "representment_strategy", "value": "fight" }, { "name": "evidence_sent_at", "value": "2026-05-31T13:00:00Z" } ] ``` Metadata can support: - BigQuery reporting - External provider reconciliation - Risk workflows - Chargeback mitigation status tracking - Customer-level chargeback analysis - AI Assistant classification - Internal support/risk queues - Third-party AI Agent workflows --- # Metadata Replacement Warning The schema exposes `metadata` as an array. When editing metadata arrays, MCP should be careful because array edits often replace the supplied array rather than appending to it. Recommended safe behavior: ```text If editing metadata, provide the complete intended metadata array unless the API explicitly supports append/merge behavior. ``` Do not assume that sending one metadata object will append to existing metadata. If the user wants to add one metadata value, MCP should first know the existing metadata values and then send the full desired final metadata array, if replacement behavior applies. --- # Third-Party Chargeback Management Workflows `EditChargeback` is important for third-party chargeback management companies because the chargeback lifecycle changes after the initial record is created. A third-party provider may: 1. Create the chargeback in RevCent. 2. Request evidence. 3. Use `CreateChargebackDocument`. 4. Submit representment. 5. Update the chargeback to mark representment initiated. 6. Later update the outcome to won or lost. 7. Store external case IDs and statuses in third-party fields or metadata. Example workflow: ```text Chargeback created ↓ CreateChargebackDocument generates evidence ↓ Third-party provider submits representment ↓ EditChargeback sets representment.initiated = true ↓ Outcome received later ↓ EditChargeback sets representment.completed = true and outcome = won/lost ``` This lets RevCent remain aligned with the external provider’s case lifecycle. --- # Relationship to `CreateChargebackDocument` `EditChargeback` updates the chargeback record and representment status. `CreateChargebackDocument` creates the evidence package used to fight the chargeback. If a chargeback is being fought, the workflow may look like: ```text CreateChargeback ↓ CreateChargebackDocument ↓ Evidence submitted ↓ EditChargeback: representment initiated ↓ EditChargeback: representment completed and outcome recorded ``` `CreateChargebackDocument` can create a ZIP containing: - Friendly formatted `.docx` - Raw `document_json` `.json` Important: ```text Document URLs expire after 24 hours. ``` Chargeback documents can include evidence such as: - Customer details - Sale details - Product details - Transaction details - Gateway details - Customer card reference/BIN details - Shipping/tracking details - Tracking visitor details - IP/device details - Fraud detection details - Metadata - Original API request context --- # Customer-Level Chargeback Tracking Editing chargebacks accurately improves customer-level chargeback history. A chargeback record may be related to a customer. That customer history can support: - Customer risk review - Manual support review - Do-not-sell decisions - Customer blocking or disabling - Customer Group qualification - BigQuery reporting - AI Assistant summaries - Third-party risk evaluation - Suppression from marketing or sales outreach - Prevention from repurchasing when appropriate Representment outcome can also influence customer risk. Example: ```text Customer has chargeback ↓ Representment lost ↓ Customer may be added to Lost Representment Customer or Do Not Sell group ``` Example: ```text Customer has chargeback ↓ Representment won ↓ Customer may still be reviewed, but risk interpretation may differ ``` --- # Reporting Value of `EditChargeback` Editing chargeback details and representment fields allows better reporting. Use BigQuery for metrics, counts, grouping, aggregations, and trends. Examples of reporting enabled by accurate edits: ```text How many chargebacks were fought? ``` ```text How many chargebacks were not fought? ``` ```text How many representments are pending? ``` ```text How many representments were won? ``` ```text How many representments were lost? ``` ```text What is the representment win rate? ``` ```text Which reason codes have the highest win rate? ``` ```text Which chargeback mitigation company has the best results? ``` ```text Which campaigns generate chargebacks that are not worth fighting? ``` ```text Which customers have lost chargebacks? ``` ```text Which products have the highest chargeback loss rate? ``` Important: ```text Do not use list operations for counting, aggregations, or reporting metrics. Use BigQuery for reporting. ``` --- # Example Requests ## Update Amount and Reason Code ```json { "chargeback_id": "XXXXXXXXXXXXXXXXXXXX", "amount": 99.95, "reason_code": "13.1" } ``` --- ## Update Case Number and ARN ```json { "chargeback_id": "XXXXXXXXXXXXXXXXXXXX", "case_number": "CB-123456789", "arn": "12345678901234567890123" } ``` --- ## Update Dates ```json { "chargeback_id": "XXXXXXXXXXXXXXXXXXXX", "chargeback_date": "2026-05-28T14:30:00Z", "received_date": "2026-05-29T09:00:00Z" } ``` --- ## Update Third-Party IDs ```json { "chargeback_id": "XXXXXXXXXXXXXXXXXXXX", "third_party_chargeback_id": "external_cb_123456", "third_party_order_id": "external_order_987654" } ``` --- ## Mark Representment Initiated ```json { "chargeback_id": "XXXXXXXXXXXXXXXXXXXX", "representment": { "initiated": true, "initiated_date": "2026-05-30T10:00:00Z", "outcome": "pending" } } ``` --- ## Mark Representment Won ```json { "chargeback_id": "XXXXXXXXXXXXXXXXXXXX", "representment": { "completed": true, "completed_date": "2026-06-15T12:00:00Z", "outcome": "won" } } ``` If `initiated` was not already set, include accurate initiated fields: ```json { "chargeback_id": "XXXXXXXXXXXXXXXXXXXX", "representment": { "initiated": true, "initiated_date": "2026-05-30T10:00:00Z", "completed": true, "completed_date": "2026-06-15T12:00:00Z", "outcome": "won" } } ``` --- ## Mark Representment Lost ```json { "chargeback_id": "XXXXXXXXXXXXXXXXXXXX", "representment": { "completed": true, "completed_date": "2026-06-15T12:00:00Z", "outcome": "lost" } } ``` If `initiated` was not already set, include accurate initiated fields: ```json { "chargeback_id": "XXXXXXXXXXXXXXXXXXXX", "representment": { "initiated": true, "initiated_date": "2026-05-30T10:00:00Z", "completed": true, "completed_date": "2026-06-15T12:00:00Z", "outcome": "lost" } } ``` --- ## Update Metadata ```json { "chargeback_id": "XXXXXXXXXXXXXXXXXXXX", "metadata": [ { "name": "external_case_status", "value": "evidence_submitted" }, { "name": "representment_strategy", "value": "fight" } ] } ``` --- # MCP Decision Process Before calling `EditChargeback`, MCP should determine: 1. Which chargeback should be edited? 2. What is the `chargeback_id`? 3. Which fields actually need to change? 4. Is this only a basic detail update? 5. Is representment being updated? 6. Was the chargeback fought? 7. If fought, when was representment initiated? 8. Is the representment still pending? 9. Has the representment completed? 10. If completed, was the outcome `won` or `lost`? 11. Are dates known accurately? 12. Are third-party IDs available? 13. Is metadata being added or replaced? 14. Should existing metadata be preserved? 15. Is the edit needed for reporting? 16. Should a chargeback document be created first or referenced? 17. Should customer-level risk workflows happen after the edit? 18. Should the customer be added to a Customer Group or reviewed? 19. Should BigQuery reporting be used to measure outcomes? --- # Validation Checklist Before submitting `EditChargeback`: 1. `chargeback_id` is present. 2. Only fields that should be edited are included. 3. `amount`, if included, is accurate and not guessed. 4. `arn`, if included, is from a reliable source. 5. `case_number`, if included, matches the external case. 6. `reason_code`, if included, is not invented. 7. `chargeback_date`, if included, is ISO8601. 8. `received_date`, if included, is ISO8601. 9. Third-party IDs are included only when relevant. 10. Metadata name/value pairs are valid. 11. Existing metadata preservation has been considered. 12. Representment fields are included only when accurate. 13. `initiated` is set only if representment truly started. 14. `initiated_date` is accurate if provided. 15. `completed` is set only if representment truly completed. 16. `completed_date` is accurate if provided. 17. `outcome` is one of `pending`, `won`, or `lost`. 18. Final outcome `won` or `lost` is used only when the result is known. 19. Read-only-once-set representment fields are treated carefully. 20. Reporting meaning has been considered: fought, not fought, pending, won, lost. 21. Follow-up workflows are considered: customer group, risk review, BigQuery, chargeback document, external provider sync. --- # Common Mistakes ## Mistake: Marking Representment Initiated When It Was Not Fought Wrong: ```json { "chargeback_id": "XXXXXXXXXXXXXXXXXXXX", "representment": { "initiated": true, "outcome": "pending" } } ``` if no representment was actually submitted. Correct: ```json { "chargeback_id": "XXXXXXXXXXXXXXXXXXXX", "reason_code": "13.1" } ``` and leave representment uninitiated. --- ## Mistake: Marking Won/Lost Too Early Do not set: ```json "outcome": "won" ``` or: ```json "outcome": "lost" ``` until the final representment outcome is known. Use: ```json "outcome": "pending" ``` when representment is still in process. --- ## Mistake: Guessing Dates Do not guess: ```text initiated_date completed_date chargeback_date received_date ``` Use the actual dates from the merchant, gateway, processor, issuer, or chargeback management provider. --- ## Mistake: Assuming `EditChargeback` Can Change the Original Transaction `EditChargeback` does not include `transaction_id` or `gateway_transaction_id`. It cannot be used to re-associate the chargeback with a different transaction. --- ## Mistake: Assuming `EditChargeback` Can Void or Refund `EditChargeback` does not include `void_transaction`. It is not used to void/refund the transaction. --- ## Mistake: Using List Operations for Reporting Do not use chargeback list operations for counts, totals, or rates. Use BigQuery. --- # Output Schema A successful response returns: ```json { "api_call_id": "XXXXXXXXXXXXXXXXXXXX", "api_call_unix": 1740000000, "code": 1, "chargeback_id": "YYYYYYYYYYYYYYYYYYYY", "result": "..." } ``` Fields: | Field | Description | |---|---| | `api_call_id` | 20-character API call ID. | | `api_call_unix` | Unix timestamp when the API call was initiated. | | `code` | API response code. `1` indicates success. | | `chargeback_id` | 20-character chargeback ID edited by the operation. | | `result` | Human-readable result message. | --- # Quick Reference Minimum request shape: ```json { "chargeback_id": "XXXXXXXXXXXXXXXXXXXX" } ``` Mark fought/pending: ```json { "chargeback_id": "XXXXXXXXXXXXXXXXXXXX", "representment": { "initiated": true, "initiated_date": "2026-05-30T10:00:00Z", "outcome": "pending" } } ``` Mark fought/won: ```json { "chargeback_id": "XXXXXXXXXXXXXXXXXXXX", "representment": { "completed": true, "completed_date": "2026-06-15T12:00:00Z", "outcome": "won" } } ``` Mark fought/lost: ```json { "chargeback_id": "XXXXXXXXXXXXXXXXXXXX", "representment": { "completed": true, "completed_date": "2026-06-15T12:00:00Z", "outcome": "lost" } } ``` Most important rules: ```text EditChargeback requires chargeback_id. Only include fields being edited. Representment fields are critical for fought/won/lost/not-fought reporting. Do not set representment as initiated unless the chargeback is actually being fought. Do not set won/lost until the final outcome is known. Use BigQuery for chargeback reporting metrics. Use CreateChargebackDocument when evidence is needed to fight a chargeback. ``` --- Document Parent Directory * [Operations](https://revcent.com/documentation/markdown/mcp/operation/index.md) - AI/MCP details and overviews for operations available within the RevCent MCP.