1. Contextual Scope Is API-Focused
Brick MCP provides structured API knowledge and integration context. It does not:
• Execute transactions
• Access live transaction data
• Perform real-time status checks
• Replace Brick backend services
Best practice:
Use MCP for guidance and generation—not runtime operations.
2. It Reflects Structured Knowledge, Not Business Overrides
Brick MCP represents defined API behavior. It does not:
• Override bank-side operational behavior
• Predict intermittent downstream issues
• Replace official SLA or compliance documentation
Best practice:
Always confirm production-critical behavior with official documentation or support channels.
3. No Guaranteed Real-Time Sync with Internal Changes
If API changes occur, there may be a propagation window before MCP reflects updates.
Best practice:
Validate against latest official API changelogs during production releases.
4. AI Interpretation Layer Still Applies
Even though MCP provides structured knowledge, the AI client still interprets it.
That means:
• Output can vary slightly per client
• Generated examples still require validation
Best practice:
Treat AI output as draft assistance, not authoritative source code.
5. No Business Logic Enforcement
Brick MCP does not enforce:
• Idempotency rules
• Callback implementation correctness
• Client-side retry logic
It explains structure—but implementation responsibility remains with the engineering team.
Before You Go Live ✅
• MCP connection verified in your AI client
• Sandbox integration validated
• Error handling implemented
• Callback handling tested
• Production endpoint configuration verified
• Team aware authentication policy may change
• AI-generated payloads manually reviewed
Common Integration Mistakes to Avoid ❌
• Treating AI output as production-ready without validation
• Skipping sandbox testing
• Confusing endpoint structure with business approval logic
• Ignoring downstream bank behavior
• Failing to implement proper callback handling