DEV Community: AdaptivANZ

How to Validate JSON and XML Payloads in Azure API Management

AdaptivANZ — Tue, 14 Oct 2025 04:21:45 +0000

by Harris Kristanto

In this vlog, I will be walking you through how to use the validate-content policy in Azure API Management (APIM) to enforce strict validation rules on incoming request payloads. This is especially useful when you want to ensure that clients send well-formed and semantically correct data before it reaches your backend.

What is validate-content?

The validate-content policy allows you to inspect and validate the body of incoming requests. You can define rules such as:

Maximum payload size
Content type enforcement
Schema validation (JSON or XML)

Limitations of validate-content Policy:

No support for conditional logic such as if-then-else statements
No partial validation as it validates the entire payload against the schema. You can’t selectively validate only certain fields or sections.
Validation happens at the gateway level. For large payloads or high-throughput APIs, this can introduce latency and impact performance.

Limitations of XML validation:

More verbose and harder to maintain than JSON
Schema complexity can impact readability and maintainability

Here’s the policy snippet I used in the demo:

<policies> 
    <inbound> 
        <base /> 
        <validate-content unspecified-content-type-action="prevent" max-size="102400" size-exceeded-action="prevent" errors-variable-name="requestBodyValidation"> 
            <content type="application/json" validate-as="json" action="prevent" schema-id="JSONSchema" /> 
        </validate-content> 
        <mock-response status-code="200" content-type="application/json" /> 
    </inbound> 
    <backend> 
        <base /> 
    </backend> 
    <outbound> 
        <base /> 
    </outbound> 
    <on-error> 
        <base /> 
    </on-error> 
</policies>

This configuration ensures that:

Only JSON payloads are accepted.
Payloads larger than 100 KB are rejected.
The content must match the schema defined by JSONSchema.

JSON Schema Explained

Here’s the schema I used to validate incoming requests:

{ 
  "type": "object", 
  "properties": { 
    "username": { 
      "type": "string", 
      "minLength": 5, 
      "maxLength": 20, 
      "pattern": "^[a-zA-Z0-9_]+$" 
    }, 
    "email": { 
      "type": "string", 
      "format": "email", 
      "maxLength": 100 
    }, 
    "age": { 
      "type": "integer", 
      "minimum": 18, 
      "maximum": 99 
    } 
  }, 
  "required": ["username", "email", "age"] 
}

Schema Rules:

username: Must be alphanumeric (including underscores), 5–20 characters.
email: Must be a valid email format, max 100 characters.
age: Must be an integer between 18 and 99.

Postman Demo Scenarios

In the video, I used Postman to test various payloads:

✅ Happy Path

Request Payload

{ 
  "username": "user123", 
  "email": "user@example.com", 
  "age": 25 
}

Response:

200 OK Response

This payload passes all validation checks.

❌ Invalid Age

{ 
  "username": "user123", 
  "email": "user@example.com", 
  "age": 16 
}

Response:

{ 
    "statusCode": 400, 
    "message": "Body of the request does not conform to the definition which is associated with the content type application/json. Path:age Message: Integer 16 is less than minimum value of 18. Line: 4, Position: 11 SchemaId: #/properties/age" 
}

This payload fails because age is below the minimum of 18.

❌ Invalid Email

{ 
  "username": "user123", 
  "email": "not-an-email", 
  "age": 25 
}

Response:

{ 
    "statusCode": 400, 
    "message": "Body of the request does not conform to the definition which is associated with the content type application/json. Path:age Message: Integer 16 is less than minimum value of 18. Line: 4, Position: 11 SchemaId: #/properties/age" 
}

This payload fails due to incorrect email format.

❌ Missing Field

{ 
  "username": "user123", 
  "age": 25 
}

Response:

{ 
    "statusCode": 400, 
    "message": "Body of the request does not conform to the definition which is associated with the content type application/json. Path: Message: Required properties are missing from object: email. Line: 4, Position: 1 SchemaId: #" 
}

This payload fails because the email field is required.

Validating XML Message Example

You can also validate XML payloads using a similar approach. Here’s an example policy snippet:

<validate-content max-size="102400" size-exceeded-action="prevent" errors-variable-name="requestbodyvalidation"></validate-content max-size="102400" size-exceeded-action="prevent" errors-variable-name="requestbodyvalidation"> 
    <content type="application xml" validate-as="xml"  action="prevent"  schema-id="XMLSchema"  =""></content type="application>

And a sample XML schema (XSD):

<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema" 
           targetNamespace="http://example.com/user" 
           xmlns="http://example.com/user" 
           elementFormDefault="qualified"> 

  <xs:element name="user"> 
    <xs:complexType> 
      <xs:sequence> 
        <xs:element name="username" type="UsernameType" /> 
        <xs:element name="email" type="EmailType" /> 
        <xs:element name="age" type="AgeType" /> 
      </xs:sequence> 
    </xs:complexType> 
  </xs:element> 

  <!-- Username: 5-20 characters, alphanumeric with underscores --> 
  <xs:simpleType name="UsernameType"> 
    <xs:restriction base="xs:string"> 
      <xs:minLength value="5"/> 
      <xs:maxLength value="20"/> 
      <xs:pattern value="^[a-zA-Z0-9_]+$"/> 
    </xs:restriction> 
  </xs:simpleType> 

  <!-- Email: valid format, max 100 characters --> 
  <xs:simpleType name="EmailType"> 
    <xs:restriction base="xs:string"> 
      <xs:maxLength value="100"/> 
      <xs:pattern value="[^@]+@[^@]+\.[^@]+" /> 
    </xs:restriction> 
  </xs:simpleType> 

  <!-- Age: integer between 18 and 99 --> 
  <xs:simpleType name="AgeType"> 
    <xs:restriction base="xs:integer"> 
      <xs:minInclusive value="18"/> 
      <xs:maxInclusive value="99"/> 
    </xs:restriction> 
  </xs:simpleType> 

</xs:schema>

Sample XML Payload:

<user xmlns="http://example.com/user"> 
  <username>user_123</username> 
  <email>user@example.com</email> 
  <age>25</age> 
</user>

Final Thoughts

Using validate-content in APIM is a powerful way to enforce data integrity and reduce backend errors. Whether you’re working with JSON or XML, schema validation ensures that only well-formed and valid data reaches your services.

Recommended Use Cases

Early payload validation: Catch malformed or incomplete requests before they hit your backend.
Enforcing contract compliance: Ensure clients adhere to expected request formats (e.g., required fields, data types, value ranges).
Reducing backend load: Filter out invalid requests at the gateway level to save processing time and resources.

When Not to Use It

Business logic validation: Avoid using validate-content for rules like “if the user selects ‘premium’, the payment method must be provided.” These kinds of conditional dependencies between fields are better handled in your backend or application logic, where you have full control over context and flow.
Every single endpoint: Use it selectively—typically on public-facing or critical endpoints where schema enforcement adds real value.
Highly dynamic schemas: If your payload structure changes frequently or is client-defined, static schema validation may become a maintenance burden.

Mocking APIs in Azure: An Overview with Practical Examples

AdaptivANZ — Tue, 14 Oct 2025 04:14:06 +0000

by Tim Brichau

APIs (Application Programming Interfaces) have changed the way data transfers between applications and services. It has been at the heart of the digital transformation we have seen over the past decade or so. Working effectively and efficiently with APIs as a developer is fundamental to being able to successfully deliver digital transformation projects in the modern world. Without APIs, the digital transformation we have seen over the last few years would not be possible.

Why Mock APIs on Azure?

The challenge when working with APIs as a developer can be that sometimes you don’t want to, or can’t, connect to a live API during development, whether because the API isn’t ready, or the API connects to sensitive or live data. These limitations can inhibit the scope of your development and testing to a degree that makes it very difficult to produce high quality applications.

This is where API mocking comes in. API mocking is where a dummy version of an API is spun up that produces a pre-defined and static output that lines up with what the intended API will produce. This allows the developer to develop and test against a production-like equivalent of any API without needing to call the live version of it.

How to Mock APIs on Azure

Azure is a great platform for mocking APIs; it supports several services that enable API mocking to various requirements and needs. Through API Management (APIM), you can quickly and easily setup mock APIs that return responses in accordance with any given API specification. You can create serverless mocks using Azure Functions to return responses exactly as you’d like them, all of which can integrate neatly with Azure DevOps to align with your CI/CD (Continuous Integration/Continuous Deployment) goals.

Practical Examples: Mocking with APIM

So, what are some practical examples?

Perhaps the most commonly used method of mocking APIs in Azure is with Azure APIM. APIM is an incredibly powerful API hosting service that is perfect for mocking APIs. All you need to do is import an API specification, and through the built-in ‘mock response’ policy, it will return responses exactly as outlined in the API specification. It’s that simple. Beyond that, you can do some more complicated logic, such as routing conditionally to a mocked or real operation within an API, or to entirely different APIs altogether.

Policies within APIM are very customisable and allow for complex logic beyond simple API operations. One specific use case for this could be when working with an API that isn’t live or ready yet, but the API specification is defined. I have worked on one project where this was the case. A downstream API was being developed at the same time as the integration, but only the API specification was ready, so we set up a mocked API to enable us to begin development before the downstream API was ready. This allows developers to code against the mock and have something to test against, and then when the actual API is live, the mock can be decommissioned with minimal friction.

Practical Examples: Mocking with Azure Functions

Another practical example of mocking is with Azure Functions. As a serverless code hosting platform, Azure Functions allows for full Object-Oriented Programming (OOP) language code projects to be deployed and running within Azure. This means a developer could write a function to return mocked responses given any code logic to mimic eventual production functionality. This can be done by passing in any given parameter that can resolve into logic to return any desired response. For example, you could pass in a response code parameter, and the function then returns a mocked response with that response code, which can help satisfy different tests.

One example in which I have done something like this is using the ‘NSubstitute’ package, specifically for unit tests. This allows you to create unit tests where external systems can return mocked data, which allows you to test your code in its entirety. Similarly to APIM, this can enable HTTP requests to a function that will eventually reach live downstream endpoints, without needing to call live endpoints. This allows for earlier and more robust testing. One specific use case for this could be mocking an external request within a function, so that the entirety of a function can be unit tested without needing external access.

Tips for Mocking APIs on Azure

What are some best practices when working with mocking, particularly within Azure?

As with anything in Azure, using proper resource tags and naming conventions is essential, as it can clearly inform any user of an API’s mocked nature. Confusing real world and mocked responses is a recipe for disaster and should be avoided where possible.
Documenting mocked behaviour clearly in wikis or repos is another way of avoiding this confusion, while also guiding a user on how the mocked API is intended to be used.
Avoiding business logic is important to keep the lines between what is being tested and what is being faked clear. The goal is not to replicate the full behaviour of the endpoint, just the output.
Finally, mock lifecycle is worth considering. The goal of a mocked API is always to remove it at some point, defining a clear stage where the mocked API should be decommissioned could be helpful, such as before going to Test.

Conclusion

Mocked APIs are borderline essential when delivering digital transformations. Particularly for cloud platforms like Azure where the strengths come from scalability, mocking APIs allows developers to develop earlier, have more robust testing and ultimately reduce cost for the project. This results in a more reliable platform all while reducing development complexity and making any project easier to manage. It is a must-have tool in the belt of any developer working with APIs.

Making Sense of Azure API Center: Discoverability with Guardrails

AdaptivANZ — Tue, 14 Oct 2025 02:39:10 +0000

by George Phillips

Integration services are a critical part of most organisations, and with that comes an ever-growing number of APIs built and managed by different teams, platforms, and business units. One problem that consistently comes up is API discoverability. When a team wants to deliver a new integration, the first question is often whether something similar already exists. Without a clear answer, people waste time asking around or rebuilding what is already out there.

The issue is not limited to duplication. Lack of visibility leads to delays, misalignment, and inconsistent implementation of standards. Product owners and developers spend cycles trying to locate what should be obvious. Architects struggle to apply governance when there is no shared view of existing APIs. The more complex the environment, such as hybrid cloud or multiple gateways, the harder this becomes.

There is also a governance challenge. When APIs are scattered or undocumented, it becomes difficult to apply consistent standards or support reuse across teams. Governance only works when people can see what they are governing, and when foundational practices like ownership, documentation, and versioning are clearly defined and followed.

This is where a central API catalogue can make a difference. In the Azure ecosystem, Azure API Center is designed to address these problems. It does not replace your API gateway or fix poor internal API design processes, but when built on good foundations, it helps improve discoverability, governance, and integration agility across the organisation. This is why it is worth considering for organisations aiming to improve integration agility at scale.

What is Azure API Center?

The Azure API Center helps organisations bring structure, visibility, and consistency to their API landscape. It acts as a central place to register, catalogue, and discover APIs, regardless of where they are hosted or how they are exposed. While it doesn’t handle runtime traffic like an API gateway, it solves upstream problems around visibility, governance, and reuse by providing a unified view of all APIs across the organisation.

Before diving into features, it’s worth emphasising that API Center’s value depends heavily on how well it’s implemented and maintained.

The Foundation of API Center

API Center is only as useful as the information it holds. For it to drive real outcomes, a few foundational practices need to be in place:

Clear API ownership: Every API should have an assigned team or individual responsible for its lifecycle, metadata, and documentation.
Consistent metadata standards: Fields like domain, version, lifecycle status, and contact details should be uniformly applied.
Reliable documentation: Links to specs, usage examples, or developer portals should be current and accessible.
Agreed governance processes: Teams should follow a shared model for registering and maintaining APIs.

Discoverability Through a Unified Catalogue

One of the key problems Azure API Center solves is helping teams find what already exists before building something new. It does this by acting as a single, searchable catalogue of APIs across the organisation, regardless of where those APIs are hosted.

APIs in API Center can be tagged with structured metadata such as domain, environment, lifecycle stage, and owning team. This allows users to filter by practical criteria. For example, a user can look for production-ready finance APIs that are owned by the data platform team. Each API entry includes links to documentation, version history, and ownership details. This helps teams assess relevance quickly and reduces the need for meetings just to get basic context.

The experience of discovery is delivered through a few key interfaces:

The Azure Portal, where API Center is managed like any other Azure resource.
The API Center Portal (currently in preview), which offers a more focused UI for browsing, filtering, and inspecting APIs.
The Visual Studio Code extension, which brings API discovery directly into the developer’s workflow. Developers can search APIs, view metadata, and open API specs without leaving their IDE.

Context Through Metadata and Documentation Links

Finding an API is only the first step. The next challenge is understanding what it does, whether it is still in use, and how to consume it. Azure API Center addresses this by allowing each API entry to be enriched with metadata and links that provide the necessary context up front.

You can assign structured metadata to each API version, including:

Lifecycle status (for example, production, preview, deprecated)
Owning team or contact person
Business domain and environment
System of record or source application
Tags for classification, such as internal, partner, or public

This information helps users quickly understand the purpose, status, and scope of the API. For example, if an API is marked as deprecated, teams know to avoid it. If it is marked as production and maintained by a specific team, they know who to contact or where to raise questions.

API Center also supports linking to external documentation. This includes OpenAPI specs, developer portals, Postman collections, or internal knowledge base articles. Providing direct access to this information removes the guesswork. Consumers can validate request and response formats, authentication models and example payloads without needing to dig through other systems or contact multiple teams.

When metadata and documentation are used properly, API Center does more than just list APIs. It gives teams enough clarity to evaluate them without needing to chase down information or schedule a call. This speeds up decision-making and lets people focus on how they will use the API, rather than figuring out what it actually does.

Governance Support Through Standardisation

Standardisation is a core part of API governance, and Azure API Center supports it not just through metadata enforcement, but also by allowing you to validate API design directly through automated API analysis.

This analysis can be configured in two ways:

Microsoft-managed analysis is built-in and requires no setup. It automatically applies a set of predefined rules based on Microsoft’s recommended API design guidelines. These rules cover common issues such as inconsistent naming, missing operation summaries, untyped responses, and invalid status codes.
Self-managed analysis allows you to bring your own rule set using tools like , a widely used open-source API linter. You define your custom rules in a Spectral ruleset file, a widely used open-source API linter. You define your custom rules in a Spectral ruleset file, host it in a publicly accessible location, and configure your API Center project to reference it. Once configured, API Center will automatically run your Spectral rules against registered OpenAPI specs and surface any issues directly in the portal.

When an OpenAPI specification is registered or updated in API Center, the selected rule set is applied automatically. The analysis results are shown in the portal, making it easy for developers and platform teams to identify and fix issues early.

This approach makes governance tangible. Instead of relying on documents and checklists, you define standards as code and apply them consistently. It reduces the need for manual reviews, improves design quality, and helps scale governance across teams.

Compatibility Across Platforms and Environments

Most organisations operate in mixed environments where APIs are distributed across multiple platforms. These may include Azure API Management, AWS API Gateway, on-premises systems, legacy services, and integration platforms like MuleSoft. This fragmentation makes it hard to get a full picture of the API landscape, let alone apply consistent governance.

Azure API Center is designed to be gateway-agnostic. You can register APIs regardless of where they are hosted, as long as you can supply the necessary metadata and, ideally, an OpenAPI specification. This allows you to include APIs from both modern cloud platforms and older systems that expose REST endpoints directly.

Support for registering APIs from platforms outside of Azure, such as MuleSoft, is still evolving. At the moment, this typically involves manually importing the API definition or automating it through CI/CD pipelines. Native integration with third-party providers is not yet fully available but is part of Microsoft’s roadmap for API Center.

This gives teams the flexibility to keep using the platforms that make sense for their workloads, without sacrificing visibility. API Center focuses on surfacing what exists, not forcing everything into a single runtime model. That makes it easier to build shared awareness across teams, even when the underlying tech stack remains diverse.

Automation and Integration into Delivery Workflows

A central API catalogue is only valuable if it reflects what actually exists in your environment. If registration is manual or treated as an afterthought, it often falls out of sync. Azure API Center addresses this by supporting automation that fits naturally into existing delivery workflows.

You can register and update APIs using:

ARM templates or Bicep, for infrastructure-as-code integration
The Azure CLI, for scripting or DevOps pipelines
The REST API, for full programmatic control over projects, APIs and versions

This allows teams to automate tasks like registering new API versions during deployment, updating lifecycle states post-release, and linking to documentation directly from the CI/CD process. It removes manual effort and ensures the catalogue stays current without additional overhead.

API Center also supports automatic synchronisation with both Azure API Management (GA) and Amazon API Gateway (Preview). This allows APIs from these platforms to be automatically discovered and registered in API Center, further reducing friction and improving catalogue accuracy across environments.

With this level of automation, it’s a good time to revisit your API lifecycle process. Registering APIs in API Center shouldn’t be treated as a one-off task. Instead, it becomes part of a broader workflow that includes versioning, publishing, deprecation and ownership tracking. Automating these steps pushes teams to formalise their approach, reinforce metadata standards and treat APIs as long-lived, managed products rather than isolated deliverables.

When automation is combined with well-defined processes, API Center becomes more than a static registry. It becomes a reliable source of truth that reflects the state of your APIs and the standards you want teams to follow.

Alignment with Azure-native Governance and Identity

Azure API Center is a native Azure resource and integrates directly with the platform’s governance and identity framework. That alignment is particularly important in environments where multiple teams contribute to or consume APIs, and where tightly controlled access is essential.

Access is managed using Azure Role-Based Access Control (RBAC), with built-in roles that support a range of responsibilities:

Azure API Center Service Reader: Read-only access to the API Center resource. Ideal for product or consumer teams that need visibility without modification rights.
Azure API Center Data Reader: Grants access to read API metadata and details at the data plane level.
Azure API Center Service Contributor: Full access to create and manage API Center projects, APIs and versions.
Azure API Center Compliance Manager: Allows management of compliance rule sets and analysis configurations.
Custom roles can also be created to support more specific access needs. For example, a team might be permitted to register new APIs but not delete existing ones, or be limited to APIs tagged with a specific domain. This provides tighter control without blocking legitimate usage. And for those who enjoy crafting deeply specific access models, custom roles offer the flexibility to go as granular as needed.

Access can be scoped at the subscription, resource group, or project level, depending on how your organisation is structured. That flexibility makes it easier to give integration, platform, product, and architecture teams access to what they need, while keeping permissions appropriately aligned to their roles.

Honourable Mention: Support for Model Context Protocol (MCP) Server

Azure API Center now supports the ability to register and discover Model Context Protocol (MCP) servers, a new integration point that helps surface APIs and tools exposed to AI agents or external systems. MCP is an emerging open protocol that allows external models to access services like APIs and knowledge bases in a structured, discoverable way.

In practical terms, this means you can now register MCP servers within your API Center project, classifying them by environment, endpoint, and other metadata. Each MCP server includes basic metadata and a lightweight OpenAPI definition that represents the APIs or capabilities it exposes. These entries are treated similarly to traditional APIs, making them part of the central catalogue available to internal teams or platform tooling.

From an integration perspective, this can be useful where AI agents or external platforms are being introduced into workflows and need to interact with existing services. For example, a vendor-hosted MCP server exposing a data enrichment API could be registered and tracked alongside internal services, helping platform and integration teams manage visibility, ownership, and lifecycle in one place.

Microsoft continues its effort to support more modern integration patterns and as with other parts of API Center, the benefit comes from applying clear metadata, ownership, and governance practices to make it part of a well-managed API portfolio.

Conclusion

Azure API Center is shaping up to be a useful addition for organisations aiming to improve API discoverability and governance in a way that aligns with existing Azure practices. It integrates well with native platform features, supports flexible access control, and encourages better API lifecycle and design standards when backed by strong foundations.

Microsoft continues to actively develop the platform, with a healthy roadmap that includes expanded provider support and further automation capabilities.

While the post presents the experience as smooth and well-structured, that may not always reflect reality. There are areas where the platform can improve. However, those considerations are better suited for a separate discussion, as this overview has already covered a lot of ground.

Model Context Protocol (MCP) in Enterprise Integration

AdaptivANZ — Sun, 12 Oct 2025 23:37:54 +0000

Author: Aseem Chiplonkar

Enterprise integration is a complex challenge that requires seamless communication between disparate systems, applications, and data models. The Model Context Protocol is a new standard that promises to transform how AI systems integrate with existing business infrastructure.

Large Language Models (LLMs) used by AI Agents and AI workflows are increasingly becoming commonplace in enterprises. They bring a reliable, integrated experience that improves productivity. To deliver on their promised benefits, these AI systems need to integrate with legacy systems, custom-built systems, and SaaS products used within the enterprise ecosystem.

The Model Context Protocol (MCP) represents a new pathway in enterprise integration architecture, offering opportunities for seamless AI-driven workflows while addressing critical challenges that have long plagued enterprises.

Some of those include:

Defining and maintaining contextual relationships between data models
Ensuring semantic interoperability between or across integrating systems
Decoupling integration logic from business logic
By the end of this article, you’ll understand how MCP facilitates integration scenarios for AI-driven enterprise workflows, while also eliciting deeper conversations and considerations for using MCP as a viable means for enterprise integration using AI Agents.

What is Model Context Protocol (MCP)?

The Model Context Protocol is an open standard designed to enable secure, standardised communication between AI models and external data sources, applications, and services. Unlike traditional integration approaches that require custom APIs and complex middleware solutions, MCP provides a unified framework for AI systems to access and interact with enterprise resources in a consistent, predictable manner.

At its core, MCP establishes a standardised way for AI models to understand context from various enterprise systems whether that’s customer data from CRM platforms, financial information from ERP systems, or operational metrics from monitoring tools. This protocol acts as a universal translator, allowing AI models to seamlessly consume and process information from disparate sources without requiring extensive custom development work.

How does MCP work?

MCP operates by establishing a contextual mapping layer between different data models.

Here’s a simplified breakdown:

Model Definition
Each system or domain defines its own data model (e.g., Customer, Order, Product).

Context Mapping
MCP creates a context-aware mapping that translates between models without requiring a rigid, unified schema.

Protocol Enforcement
Rules and transformations are applied dynamically based on the interaction context.

Execution & Mediation
MCP facilitates communication between systems while preserving each model’s autonomy.

This approach avoids the challenges of traditional point-to-point integration, where changes in one system often require updates in another.

Key Concepts in MCP

MCP is built on a flexible, extensible client-server architecture. To better understand how it fits within a real-world enterprise integration scenario, let’s go over the key concepts put forward by the protocol.

Hosts are AI applications or AI models that initiate connections.

Clients are inside the host application which maintain connectivity by adhering to MCP protocol.

Servers provide context, tools, and prompts which Hosts can utilise.

The MCP Server provides following key capabilities:

Resources
Resources are a core primitive in the Model Context Protocol (MCP) that allow servers to expose data and content that can be read by clients and used as context for prompts.

Prompts
Prompts enable servers to define reusable prompt templates and workflows that clients can easily surface to users, they are designed to be user-controlled. They give users ability to explicitly select them.

Tools
Tools are a powerful primitive in the Model Context Protocol (MCP) that enable servers to expose executable functionality to clients, they are designed to be model-controlled. This allows the AI model to invoke them on behalf of the user.

Key Principles of MCP

Shared Canonical Models
Define and distribute canonical models that represent key business entities (Customer, Invoice, Product) along with their context (source, state, ownership).

Contextual Contracts
Every service that emits or consumes data adheres to a contract that includes not just the structure of the model but its intended usage, lifecycle state, and meaning.

Model Registries
A central repository or registry governs model definitions, versioning, and backward compatibility, ensuring a single source of truth.

Context Propagation
Metadata about the model context (e.g., who transformed it, why, in what process stage) travels alongside the payload in APIs, event streams, or service calls.

Decentralised Governance
While the models are standardised, teams retain the autonomy to extend them for local needs—within guardrails defined by the protocol.

MCP-Enabled Healthcare Integration – Sample Integration Architecture

This image above is an example of how MCP can be leveraged to enable integration between source systems of different data models and schemas and AI-enabled outcomes like personalised medicine or medical imaging.

The MCP Server acts as the authoritative source of truth for canonical models e.g. patient. It holds the model registry and provides model definitions, version metadata, and context schemas.

The MCP Server leverages tools for modifying and querying data from Electronic Health Records (EHR) and Picture Archiving and Communication System (PACS) for the MCP Host to use.

The MCP Hosts make use of purpose-built MCP Clients that use Prompts and actions published by the MCP Host to seamlessly modify and query data from the downstream systems.

Why is MCP significant in Enterprise Integration for AI?

Enables Loose Coupling:
MCP reduces dependencies between integrated systems, allowing them to evolve independently. This is crucial in microservices and distributed architectures where change is constant.

Supports Semantic Interoperability:
Different departments (Sales, Finance, Logistics) often use the same terms (e.g., “Customer”) with different meanings. MCP ensures that data is interpreted correctly in each context. Unified data models reduce ambiguity and integration errors.

Simplifies Scalability by Introducing Change Resilience:
Since MCP decouples integration logic, adding new systems or modifying existing ones becomes easier without cascading changes across the enterprise. Loose coupling via context-aware contracts protects against upstream changes thereby adding change resiliency.

Reduces Integration Technical Debt:
With Unified Data Models and model registry MCP avoids proliferation of bespoke transformations and mappers thereby promoting more adaptive and sustainable models for integration.

MCP Implementation Considerations for Enterprises

While MCP offers significant benefits, successful implementation requires careful planning and consideration of several factors:

Infrastructure Readiness
Organisations must assess their current infrastructure’s readiness for MCP implementation, including network capacity, security frameworks, and data governance policies.

Change Management
Implementing MCP may require changes to existing workflows and processes. Organisations should plan for appropriate change management and training programs.

Performance Optimisation
While MCP standardises integration approaches, organisations must still optimise performance for their specific use cases and data volumes

Vendor Ecosystem
The success of MCP implementation often depends on vendor support and ecosystem development. Organisations should evaluate the MCP readiness of their existing technology stack.

Conclusion

The Model Context Protocol represents a thoughtful evolution in integration strategy when it comes to integrating with AI systems with AI workflows and AI Agents. Rather than connecting these systems the traditional way, MCP guarantees that shared understanding and context are first-class citizens of the integration architecture.

For organisations aiming to scale integration efforts, reduce fragility, and unlock agility, MCP might be the perfect solution in the integration architectural toolkit.

By adopting MCP, organisations can achieve:

Greater agility in system integration
Reduced maintenance overhead
Improved interoperability across domains

As enterprises continue to embrace cloud-native, distributed systems, MCP will play an increasingly vital role in ensuring seamless and scalable integration with AI systems.

References:

Anthropic. “Introducing the Model Context Protocol.” Anthropic.com, 2024, www.anthropic.com/news/model-context-protocol.
“Introduction – Model Context Protocol.” Modelcontextprotocol.io, Model Context Protocol, 2025, https://modelcontextprotocol.io/introduction.
“Resources – Model Context Protocol.” Modelcontextprotocol.io, Model Context Protocol, 2025, https://modelcontextprotocol.io/docs/concepts/resources.
“Tools – Model Context Protocol.” Modelcontextprotocol.io, Model Context Protocol, 2025, https://modelcontextprotocol.io/docs/concepts/tools.

A First Look at Boomi AI Agents

AdaptivANZ — Tue, 15 Jul 2025 23:34:28 +0000

Author: Thea Miguel

Yes, Boomi uses AI!

Organisations are under pressure to keep up with rapid advancements in artificial intelligence, particularly Generative AI. As Gen AI continues to reshape various industries, the need for intelligent automation becomes more urgent. According to Gartner, worldwide spending on Gen AI is projected to reach a staggering USD 644 billion in 2025 (a 76 % increase since 2024), while a recent survey by PWC says two-thirds of companies already report increased productivity by adopting AI Agents. At the same time, 88% of senior executives plan to increase AI-related budgets due to the rise of agentic AI, showing just how quickly businesses are investing in this space to stay competitive. But as interest and investment accelerate, the challenge lies in turning that momentum into scalable outcomes. To bridge that gap, Boomi has introduced AI Agents that make automation more achievable and impactful.

Whether you’re designing workflows, generating documentation, or needing assistance with your integration processes, AI Agents can enhance productivity and decision-making while keeping simplicity and accessibility at the forefront. Built intentionally for the Boomi Enterprise Platform, they streamline everyday integration tasks and accelerate your understanding of business logic. These agents have proven their success in integration and are trusted features that promote best practice and a mindful approach to the creation of your APIs. Here is a first look at some of the Boomi AI Agents.

What are Boomi AI Agents?

Boomi AI Agents are a suite of AI-powered developer tools that are capable of complex tasks such as automating business logic, enhancing data, and accelerating API integrations. From aiding in the design phase, having the capability to translate everyday language into integration steps, to the creation of documentation to support these solutions, Boomi AI Agents help teams increase productivity, provide insights, and connect applications, data, processes, people, and devices.

Businesses looking to enhance productivity and decrease the time spent trying to understand requirements will find that using Boomi GPT, DesignGen, and Scribe takes a step in the right direction. As a developer, there is a need for efficiency when delivering integration solutions so these have easily become my top 3 Boomi AI Agents. They aid in all stages of development, starting at the very basics of understanding how business requirements translate onto a process canvas.

Boomi GPT

Streamline business processes and achieve goals within the Boomi Enterprise Platform using Boomi GPT, a conversational user interface (CUI) that utilises generative AI. Use Boomi GPT to ask Boomi-related questions to help your overall experience with the platform. Whether it be a generic question related to integration concepts, or a specific one relating to your business requirements, Boomi GPT is able to do both and in a way that keeps best practices in mind. There’s no pressure to be technical because Boomi GPT is trained to understand everyday language whilst providing high-level answers, ensuring information is trustworthy and integration requirements are met.

The Benefits

The simplicity of this CUI allows you to streamline complex tasks and business logic.
Boomi GPT complements and enhances the developer experience by helping create processes and documentation.
This GPT is dedicated to responding to prompts related to Boomi.

Key Considerations

Boomi GPT currently supports the English language.
Like other GPTs, the conversation and the model’s response depend on the input received from the user.

Boomi DesignGen

Gen AI will design your integration process based on your business requirements, common patterns, and, most importantly, best practices. Feed your requests into Boomi DesignGen and watch while it creates diagrams for visualisation, while having the capability to make edits based on your feedback. Boomi DesignGen has the capability to provide a skeleton solution that meets requirements whether you’re working on different sections to enhance your process or wanting a general idea of your build. It also considers existing components in your tenancy, such as connectors, to avoid duplication.

The Benefits

DesignGen upholds use of best practices and common patterns.
Fast-tracks the design and development phase, increasing productivity.

Boomi Scribe

Boomi Scribe’s speciality is documentation, generating summaries, descriptions, and documentation for both AI-generated and existing integration processes. This AI Agent takes what could otherwise be a lengthy and tedious task and provides developers with a template to build on. When an integration process is in the development phase, the original design can change to better suit project requirements. Oftentimes, the integration process can become more complex, requiring changes to documentation to account for additional logic. Boomi Scribe steps in to analyse and translate the integration build into documentation that is understandable, and as concise or in-detail as possible.

This AI Agent is detail-oriented, noting all aspects of integration builds such as:

Main and sub processes
Components
Operations
Process schedules
Details on data flow through each step and connector

The Benefits

Boomi Scribe has comparison documentation feature that records additions, changes, deletions between two versions at a component level and process level.
Creates process diagrams.
Generates a summary of the integration process which helps teams understand the overall business process.

Conclusion

Enterprise leaders increasingly recognise the potential of Gen AI to boost productivity and efficiency. According to a 2024 KPMG survey, 79% of Australian business and technology executives expect Gen AI to drive transformation. Boomi AI Agents help turn that expectation into action by offering a practical, enterprise-ready approach to automation.

Boomi AI Agents set a new standard for integration, evidently having the capability to support developers across all skill levels and at different parts of delivery. Understand business requirements and gain a deeper understanding of Boomi concepts with the use of Boomi GPT. Boomi DesignGen ensures that you hit the ground running with a base level design that initialises your integration build, and Boomi Scribe takes the time off your hands by generating the documentation to support it. Because of these tools, developers have a deeper understanding of integration processes without compromising efficiency or accuracy. These AI Agents are Boomi-specific and enforce best practices, adding value to the way developers problem-solve, seek out resources, and produce solutions.