June 2025 Product Highlights: MCP Servers, Portal Layout Controls and more Comprehensive SDK Docs

With this month’s release, you can generate Model Context Protocol (MCP) servers directly from your OpenAPI specs, fine‑tune your API Portal layout, and include SDK infrastructure docs to make your SDK documentation more comprehensive.
We’ve also improved SDK publishing flexibility, added support for proxy configuration in SDKs and extended log retention to give you better visibility into past activity.

🏆 Featured: Award-Winning Banking AI in Action

Watch our team's winning hackathon project from API Days New York, where we built a conversational AI that transforms how we interact with our finances. 

This demo shows a user "talking" to their bank account, asking to see a dashboard for their banking transactions and then generating a mortgage payoff plan - all based on banking data fetched from FDX compliant APIs.

Seamlessly integrating multiple banking services, this demo highlights how APIMatic’s tools accelerate AI‑ready financial solutions, making complex data accessible through natural language.

Generate MCP Servers from OpenAPI Definitions

You can now generate Model Context Protocol (MCP) servers directly from your OpenAPI specifications—no extra setup required.

For users with early access, this means you can instantly create conversational interfaces for your APIs, enabling AI assistants to interact with services like banking APIs, e-commerce platforms, or any REST-based system using natural language.

We’re actively aligning our implementation with the evolving MCP standards and incorporating community feedback, so you can experiment with cutting-edge AI integrations while maintaining strong security and privacy controls.

The best part is that MCP server generation is seamless, requiring no extra setup. Simply enable it within your existing API Portal or Code Generation workflows. 

🔗 Reach out at support@apimatic.io for early access to MCP Server Generation capabilities

Customize your API Portal Layout

You can now configure precise layout controls within the theme object of your portal configuration. This feature gives you declarative control over container alignment and maximum widths, helping you create cleaner and more responsive layouts with minimal effort.

We've introduced a new layout object that allows users to set maximum widths for layout containers and define horizontal alignment for content. This will help you create visually balanced, readable layouts optimized for desktop users. With this release, you can now control both mainContainer and content alignment settings, giving you greater control over your portal's visual presentation.

The layout system automatically optimises for desktop viewports while preserving the mobile experience on tablets and smaller devices. You can choose between left and centre alignment options, with support for both pixel and rem-based maximum width values.

🔗 Read the changelog for more details.

Include SDK Infrastructure docs in your API Portal

You can now include SDK infrastructure documentation—like helper methods and utility classes—directly in your API Portal.

This means your portal provides more comprehensive documentation for the SDKs, helping developers better understand how the SDK is structured and how to use it effectively.

🔗 See the changelog for details.

Enable Native Proxy Configuration in SDKs

You can now provide proxy configurations via the SDK's native Proxy Configuration interface during client initialization.
This improves compatibility with enterprise environments that require outbound requests to pass through proxies, firewalls, or other network gateways.

Proxy configuration is supported in PHP and .NET, with support in other languages coming soon.

🔗 Learn more about Proxy configuration in the SDK features documentation.

🛠 Improvements

• Publish Source Code Without Version Tags: You can now publish SDK source code to GitHub without providing version tags. A new “Publish Source Code” button is available in the SDK Publishing UI, making the process more direct and flexible.
• Publish SDK with Language Configurations: SDK source code can now be published to GitHub with all package configurations and metadata included. This enhancement streamlines the SDK publishing process by eliminating potential inconsistencies between the SDK source code and the SDK package, specifically when both are published separately.
• Extended SDK Log & Artefact Retention: The retention period for build logs and generated SDKs has been increased from 90 days to 360 days. This gives you more time to access archived artefacts and debug long-running issues. 
• Enhanced Docs as Code API Error Responses: The API now returns more precise HTTP status codes with structured JSON error bodies for common failure scenarios. You'll receive clearer diagnostic information for validation errors (400), authentication issues (401) and access restrictions (403), making troubleshooting faster and more efficient. 
• Improved validation for Docs as Code TOC file: Runtime validation for the TOC file has been improved to provide more specific error messages in case of incorrect file paths. This improvement assists users in identifying and resolving issues related to missing file references by providing clearer guidance on which paths are incorrect and how to fix them.

🐞 Bug Fixes

• Support for Empty String Default Values: Resolved an issue where API definitions couldn't specify empty strings (“”) as default values for string-type parameters

⚠️ Deprecations & Breaking Changes

• [Breaking Change] Enhanced Path Validation in TOC Files: TOC file path handling now enforces stricter validation rules with case-sensitive file references and forward slash separators only.

Impact: Existing TOC files using mixed case or backslash separators may cause build failures. For example, docs/Getting-Started.md and docs/getting-started.md are now treated as different files.

Next steps: Review your TOC files and ensure all file path references use exact case matching and forward slash separators before your next build. 

• [Breaking Change] Standardised Line Endings in Docs as Code Output: All generated files in Docs as Code ZIP archives now use LF (\n) line endings instead of CRLF (\r\n).

Impact: Scripts or tools that expect CRLF line endings may need updates to handle the new LF-only format.

Next steps: Update your post-processing scripts and diff tools to expect LF line endings. 

📢 Share your feedback

Your feedback makes our product better.

• 🐞 Found a bug? Report it at support@apimatic.io and earn eternal developer karma
• 💡Got a brilliant idea? Schedule a 15-minute chat and share it before our product team claims they thought of it first
• 🎉 Love something we built? Tell us so we can argue less about what to build next

Follow us on LinkedIn to stay updated with the latest news from APIMatic!