This argument & article was initially sparked by some platform accessibility research I was doing via AI which uncovered the frustrating gap between what modern AI agents CAN do and what much of the software world still ALLOWS them to do in the first place.
There is a new kind of software feature that is becoming impossible to dismiss as “for developers only.”
And it’s NOT just AI for AI’s sake either…
It is the ability to participate in an open, machine-readable ecosystem.
If a software product stores your data, runs your workflow or stands between you and an important business decision, it should expose a well-documented API.
If it expects to be used with modern AI assistants, it should also expose a safe, discoverable interface for agents and THAT is increasingly via the Model Context Protocol or MCP.
That DOES NOT mean every customer should receive unlimited write access.
It DOES NOT mean an AI model should be allowed to improvise inside an accounting ledger.
It DOES mean that basic interoperability should not be treated as a luxury feature reserved for the largest customers, hidden behind a sales call, or delegated to a brittle desktop connector.
API access & MCP access should be table stakes - there, I said it.
Rate limits, premium support, advanced governance, higher throughput and enterprise controls can all still be monetized.
The right to connect the software you already pay for should not be the MOAT people!
This article began with AI assisted research I was doing about Fulfil ERP and how it compares with NetSuite and Odoo.(1)
My research exposed a deceptively simple question: which of these platforms has a native MCP server?
NetSuite was first described as lacking native MCP support. Then the answer was corrected: Oracle does provide a first-party NetSuite AI Connector Service and MCP Standard Tools SuiteApp. Oracle’s own documentation confirms that the SuiteApp can expose record, report, saved-search, and SuiteQL tools through MCP, subject to NetSuite roles and permissions.(7) (8)
That contradiction was not just another typical AI hallucination in this case.
It was actually a useful case study in why software interoperability needs to be discoverable, documented and explicit.
If an expert human researcher using AI (like I was) has to navigate vendor marketing, partner blogs, marketplace listings and incomplete product pages to determine whether an AI agent can safely reach a system, the software is already massively hindering adoption and creating unnecessary friction in the path to purchase.
The research also surfaced a second common misconception.
A modern agentic platform (eg Manus, Perplexity Computer, Grok Bot etc.) can often inspect public documentation, write a script, inject a stored secret, call a REST API endpoint, inspect errors and retry.
In this scenario, the agent BECOMES the primary integration layer and management team all in one.
But that does not automatically make well defined APIs or a comprehensive MCP layer irrelevant.
It actually makes the quality & completeness of the access layer even more important IMO.
The agent still needs something stable to discover, authenticate against, call, observe, explain and leverage for automation.
It helps to separate three common technology layers that are often compressed into one word: “integration.”
An API is the product’s programmatic surface.
It tells another system how to read data, create records, update objects, trigger workflows or receive events. A good API has predictable identifiers, clear errors, versioning, pagination, real-time webhooks and detailed + granular permissions.MCP is an interoperability layer for AI applications.
The official MCP documentation describes it as an open-source standard for connecting AI applications to external systems, including data sources, tools, and workflows.(10)
The protocol’s tools specification adds crucial detail: tools are discoverable and described with metadata and JSON Schema, so an AI client can learn what a tool does and which parameters it accepts before invoking it.(11)
The agent runtime is the execution environment around the model.
It handles the network request, signs or refreshes credentials, stores secrets, applies policy, retries failed calls, transforms verbose payloads and records what happened.
The model decides what it wants to accomplish while the runtime (the agentic execution layer) is what actually opens the connection and takes responsibility for the outcomes - both expected and unexpected.
This distinction matters because an AI agent may be able to call a raw API without an MCP server.
A capable runtime AI agent can:
Read OpenAPI documentation
Write code
Make an authenticated request
And much much more.
That is powerful, especially in the right hands - e.g. technical non-coders like me.
However, it is still a fallback, not an excuse for vendors to provide a poor agentic integration harness!
MCP is valuable because it reduces the amount of guesswork (and real work) between the agent and the system.
It can expose tool names, input schemas, resource descriptions, permission boundaries, and structured results.(12)
It can make the integration portable across clients instead of forcing every AI vendor to build a separate adapter (or the LLM to build one in real time) for every software vendor, connection or integration requirement.
It is best understood as a contract, rather than a brain.
It does not replace the model, the agent runtime, the authorization system or the business logic.
Crucially, it does not replace the API’s behind it or guarantee that a vendor has exposed its entire API capability to it.
It simply gives the AI agent a standardized way to discover and interact with the API surface that the vendor has chosen to publish.
That is why an MCP server can be both useful and frustrating at the same time.
A governed MCP tool set may be ‘safer’ than a raw API endpoint but if it covers only a narrow slice of the business system, developers (and/or agents and their human operators) will still prefer (and in many cases NEED) direct API calls for serious automation.
That is the primary agentic AI gap that legacy software vendors are struggling to fill - both technically and commercially.
Software access is not binary - as in yes/no.
A product can have an API and still be functionally closed if the API is hidden, un-versioned, poorly documented, expensive to unlock or unavailable to the plan a customer bought.
The most useful way to think about the landscape is as a spectrum.
Open by default means that every customer can obtain a documented, authenticated API connection, subject to sensible rate limits and permissions. The product may charge for volume, support, compliance, or advanced controls but it does not charge for the basic right to connect.
Open by default systems often offer MCP servers that cover the entire API surface, both internally (e.g. an MCP driven admin AI agent or chatbot) or externally for AI agents like Manus to connect to.
This is the holy grail for the software user and/or their AI agent layer.
Governed by default means that the vendor provides a first-party API or MCP surface but intentionally exposes only limited & approved tools and operations. NetSuite is a good example. Oracle’s MCP Standard Tools SuiteApp supports records, reports, saved searches, and SuiteQL, with actions constrained by the connected role’s permissions.(7) (8) This is an understandable security design but it is not the same thing as exposing every API function through MCP - which NetSuite does not do.
We can consider this the ‘better than nothing’ approach.
Gated by edition means that the capability exists but not for everyone. Salesforce’s official guidance says API access is included by default in Enterprise, Unlimited, Developer and Performance editions. Group and Essentials do not have API access and cannot purchase it as an add-on. Professional requires a separate Web Services API product.(4) This is an example of a very convoluted, gated API access model.
This is yet another ‘better than nothing’ approach.
Local by necessity means that the product can be integrated but only through a machine-local bridge, proprietary SDK or an installed connector.
That is the QuickBooks Desktop pattern.
Intuit’s official documentation describes the Web Connector as a Windows application installed on the same machine as QuickBooks or at least on the same local network, passing qbXML between a web service and the desktop product.(5) (6)
Sounds painful, lol.
This is a last resort access approach.
Select-customer access means that the vendor has an API, but self-service availability is not part of the normal product experience.
Riverside is an especially clear example. Its public pricing page lists API access under the custom-priced Business plan, not under the publicly priced Pro, Grow, or Webinar plans.(2) Its API documentation says the Business API is currently for “select Business accounts only” and instructs customers to speak to their customer success manager to generate an API key.(3)
These are not minor packaging decisions. They shape who can automate, who can build on top of the product and who gets to participate in the emerging agent economy.
This is the non-democratic access approach.
Platforms that offer none of the above should not even be considered for production use inside any serious business.
Riverside is a modern SaaS based recording and editing platform, not an old mainframe or green screen system.
That makes its access model particularly infuriating.
The product is easy to use manually.
The paid plans are designed to make recording, editing, hosting, and publishing convenient.
Yet the official pricing page places API access inside the Business tier, which is custom-priced and sold through contact with the company.(2)
The public Business API documentation is clear about the API’s purpose: it can retrieve recording media and exported edits, delete material, and register webinar attendees. It also supports webhooks.(3)
That is a meaningful API. It is not vaporware.
The issue is the access policy. A creator (like me as I use Riverside) or small production team may already be paying for the product but still be unable to connect it to an agent, archive, content pipeline, or internal workflow without entering an enterprise sales process.
I also found no first-party MCP offering in the Riverside pricing and API documentation reviewed for this article.
Third parties can build an MCP server on top of an API and community integrations can appear before vendor documentation catches up. But if the official product experience does not present a supported MCP interface, the customer is left to build or trust the bridge themselves.
Not fun and certainly not cheap.
The practical message is simple: Riverside has made its system programmable but not universally programmable or accessible.
That distinction is precisely what table-stakes access is meant to eliminate!
Salesforce is a more obvious enterprise platform and it illustrates why API access and MCP availability must be analyzed distinctly.
Salesforce’s own help article states that not all editions include API access.(4) Enterprise, Unlimited, Developer, and Performance include it by default. Group and Essentials do not have API access and cannot purchase it as an add-on. Professional can obtain it but only by purchasing the Web Services API product through an account executive.
The justification for monetizing API usage is understandable.
APIs consume infrastructure, create security responsibilities, and can expose valuable enterprise capabilities. But those concerns support rate limits, quotas, scopes, monitoring, and paid support. They do not necessarily support withholding the basic connection point from the lower tiers.
The distinction is similar to electricity in a building. A premium customer may receive more capacity, redundancy, and service guarantees. But a building where the wiring is available only after a special negotiation is not “open” merely because electricity exists somewhere on the property.
Salesforce’s MCP story is more current than its API-tier story.
Salesforce now offers first-party Hosted MCP Servers and its April 2026 general-availability announcement says the capability is production-ready for every Enterprise Edition org and above.(14) (15)
Salesforce’s documentation describes a Salesforce-managed MCP endpoint that compatible clients such as Claude, ChatGPT, Cursor and custom agents can connect to through OAuth-based authentication. The hosted servers can expose SObject operations, custom tools backed by Apex and Flows, Named Queries, Data 360 SQL, Tableau analytics, and prompt templates, while respecting the authenticated user’s permissions, field-level security, and sharing rules.(14)
That makes Salesforce neither “closed” nor fully open by default.
It is a two-layer gate: API access is unavailable or separately purchasable on some lower editions, while first-party hosted MCP is currently positioned for Enterprise Edition and above.
This is obviously better than having no MCP at all but it still reinforces the article’s central point: agent access is a product-tier decision and customers need to know about it before they buy.
For AI agents, the distinction is consequential.
Salesforce has built a governed, first-party MCP path for qualifying organizations but a customer on a lower edition cannot simply assume that the same agent workflow will be available.
A human may tolerate exporting a CSV but an agent cannot build a reliable workflow around a system it cannot access cleanly and consistently.
When API AND MCP access are unavailable, the platform becomes an island in a world where software is increasingly expected to compose with other software.
Salesforce represents the ‘2nd class citizen’ model of software access and this will increasingly become a sales barrier as the world adopts agentic workflows everywhere.
Odoo is often presented as the flexible, open alternative in ERP conversations.
Its source code and modular architecture do create genuine room for customization. But the hosted product’s API policy shows why “open” requires a precise definition.
Odoo’s official 19.0 documentation says that access to data through its external API is available only on Custom pricing plans.
It is not available on the One App Free or Standard plans.(13)
The same page documents the newer JSON-2 API and explains that operations are still validated against Odoo’s access rights, record rules, and field access controls.(13)
That is a sensible permission model wrapped in an unnecessarily narrow commercial gate.
Odoo can be flexible for the customer who buys the right tier, while remaining closed to a smaller customer who wants to connect a legitimate workflow or AI assistant.
The lesson is the same as Salesforce’s but with an important twist: open architecture and open access are not synonyms.
QuickBooks Desktop demonstrates why “it has an SDK” is not the same as “it is agent-ready.”
Intuit’s developer documentation says the QuickBooks Web Connector is a Microsoft Windows application that runs on the same machine as QuickBooks Desktop or at least on the same local network.
It passes qbXML or qbposXML between a web service and the desktop product. The web service must implement methods defined by the Web Connector WSDL.(6)
Intuit’s support documentation is even more direct: the Web Connector can only be installed where the QuickBooks file is locally saved.(5)
There is nothing inherently wrong with a local connector.
It may be the safest available architecture for a desktop accounting database. The problem is that this architecture creates a long chain of operational dependencies:
A Windows machine must be available
The company file must be reachable
The connector must be installed and authorized
The XML contract must be implemented correctly
The system must remain online when the workflow runs
An agent can work around this.
It can ask a user to open a desktop session, execute a local script or route through a third-party automation service. But every workaround increases latency, failure modes and support burden.
QuickBooks Desktop is therefore a useful warning.
A product can be “integratable” in the narrow technical sense while remaining closed to autonomous AI workflows in the practical sense.
NetSuite is where the argument becomes more nuanced.
My original research eventually found the correct answer: Oracle does support MCP through the NetSuite AI Connector Service and MCP Standard Tools SuiteApp.(7) The SuiteApp is not a generic tunnel into the entire NetSuite estate. Oracle documents a defined tool surface: record tools, report tools, saved-search tools, and SuiteQL tools.(8)
Oracle also makes the governance model explicit. The tools use NetSuite roles and permissions. Users with the relevant MCP Server Connection permission can perform supported record actions, and Oracle recommends creating dedicated roles with specific record and action permissions for greater control.(7)
This is not “bad MCP.”
It is what a risk-sensitive enterprise vendor might reasonably build. An AI agent that can update records should not automatically be able to administer the entire account, execute arbitrary server-side code or perform unconstrained bulk operations.
The criticism here is different: a narrow MCP layer can become a bottleneck when the vendor’s business system is highly customized and a developer needs exact API coverage, custom fields, surgical queries, or complex multi-step workflows.
In those cases, a direct API route may be more flexible. A capable agent runtime can store restricted credentials, inspect schemas, write a targeted request and transform the result without requiring the operator to maintain a permanent wrapper.
That does not make the native MCP layer redundant. It means the best architecture may be both: governed MCP for common, auditable operations and well-documented API access for advanced automation.
A vendor should not force customers to choose between safety and completeness.
My bigger gripes are that NetSuite still does not have 100% platform wide REST API coverage nor does it have a native Webhooks layer at all!
Real time, delta data update based integrations with NetSuite are STILL unnecessarily hard and expensive to build.
Fulfil provides the positive counterexample in the conversation.
On its official MCP page, Fulfil describes itself as an AI-native ERP with native MCP support.
It says its MCP server can expose schema discovery, SQL queries, record search, record creation and updates, reports, and documentation search.(9)
That is a meaningful AI product philosophy.
The integration is not bolted on after decades of accumulated interfaces. It is presented as part of the system’s normal operating model. Fulfil also links MCP to coding agents and says OAuth handles registration for a workspace-specific MCP endpoint.(9)
Vendor claims should still be verified in a real deployment of course and I have never used Fulfil before, but I like what I read at least.
“Native” does not automatically tell us how permissions, audit trails, approvals, rate limits or destructive actions are handled.
But the direction is right: the product treats agents as a first-class user of the system rather than as an expensive exception.
The contrast with legacy software is not that Fulfil has discovered a magic protocol. It is that the system’s data model, API, documentation and agent harness are being designed as one, unified product surface.
One of the strongest points here is that modern agentic platforms can do much more than traditional no-code tools.
Given access to documentation and secrets, an agent can write temporary Python or JavaScript, call a REST endpoint, handle authentication through its runtime, inspect an error, change the request and return a clean result.
That capability genuinely changes the economics of integration in a positive way.
The operator may not need to hire a developer to build a bespoke connector for every internal workflow.
The agent can easily perform the one-off translation at execution time.
But this does not absolve the software vendor of responsibility - especially if they want to continue to be able to sell to AI access sensitive buyers and consultants like me.
It shifts the responsibility from “build a wrapper for me” to “give me a trustworthy surface to work with.”
The vendor still needs to provide:
Stable identifiers and schemas, so the agent can discover valid objects and parameters without guessing.
Clear authentication and authorization, so the runtime can use least-privilege credentials rather than a shared administrator account.
Predictable, verbose errors/responses, so the agent can distinguish a bad request from a permission failure, rate limit, transient outage or business-rule rejection.
Webhooks and event delivery, so agents can respond to changes instead of polling forever.
Idempotency and dry-run behavior, so retries do not create duplicate orders, invoices or recordings.
Audit logs and human confirmation, so consequential actions are visible, reviewable and reversible where possible.
Portable discovery, through OpenAPI, MCP, SDKs or all three, so customers are not trapped in a single AI vendor’s ecosystem.
MCP’s own security guidance is aligned with this view:
The official specification calls for input validation, access controls, rate limiting, sanitized outputs, confirmation for sensitive operations and audit-oriented logging.(11)
An open interface is not an unguarded interface. The point is to make the guardrails explicit and machine-readable.
Ultimately, the safety and security guardrails should be implemented at the API layer and simply enforced at the MCP layer.
“API access for everyone” should not be interpreted as “every plan gets unlimited access to every internal operation.”
That is not a defensible position of course.
A reasonable table-stakes policy would give every paid plan a documented, versioned, authenticated read API, basic webhooks, export access and a supported path for connecting an AI client.
Write actions could be permissioned, rate-limited, approval-gated, or restricted to selected objects. High-volume usage, premium support, data residency, advanced observability and enterprise identity controls could remain paid features.
For MCP, table stakes should mean a supported server or an officially documented way to connect one. The minimum should include tool discovery, JSON Schemas, resource descriptions where appropriate, scoped authorization, clear user consent, and an audit trail.(12)
A vendor can expose a smaller safe tool set at first. It should not pretend that a hidden, partner-only connector is equivalent to an open product surface.
This approach is commercially healthier as well.
A product with accessible APIs becomes easier to adopt because customers can connect it to the rest of their stack.
It becomes easier to leave because data is portable but that is not a weakness…
In my 26+ years of real world industry experience, I have seen that products that win through interoperability tend to win through product quality, workflow depth, and trust rather than captivity.
The next time you evaluate software, ask questions that would have sounded unusually technical just two years ago:
Can every paid customer obtain API credentials without a sales negotiation?
Is there a current, versioned API reference with examples, schemas, error codes, and rate limits?
Are webhooks available for the events that matter or must every integration poll?
Is there an official MCP server or an officially supported path to expose the API through MCP?
Can a customer create a least-privilege role for an agent without granting full administrator access?
Are write actions idempotent, confirmable and auditable/reversible?
Can the customer export data in a useful, documented format if the product is unavailable?
Are integrations available on the plan the we are considering?
A “no” to one question may be acceptable.
A “no” to most of them should be treated as a serious product and business risk, not just an engineering inconvenience.
MCP is not a dead-on-arrival bridge protocol - though I have heard the argument for AI run time API connections as being a valid alternative to MCP…
It is also not a substitute for a good API, a secure runtime or a sensible product architecture. It is however a standard way to make tools and context universally discoverable across AI clients.
Direct API execution will remain useful, especially for legacy systems with incomplete MCP coverage.
Agents are increasingly capable of generating the glue code that humans used to maintain. But the fact that an agent can fight its way through a bad interface should not become a justification for shipping bad interfaces.
The deeper lesson from the Fulfil, NetSuite, Odoo, Salesforce, QuickBooks Desktop, and Riverside examples is that access is a product decision.
Vendors can make software open, governed, gated, or local. They can treat agents as first-class users, or they can treat them as an enterprise upsell.
The market is moving toward a simple expectation: if a human customer can use a system, an authorized agent should be able to use it easily and safely too.
The products that understand this will become infrastructure. The products that do not may remain profitable for a while but every locked door will become an adoption barrier.
The future of software is not just better interfaces for humans. It is software that can participate in a trusted network of other software.
Open by default is no longer a developer preference - it is rapidly becoming the minimum viable approach for the agentic era.
1.Gemini AI research on platform specific API/MCP accessibility and capabilities - which sparked the idea for this article
2.Riverside Plans & Pricing: https://riverside.com/pricing
3.Riverside Business API Documentation: Introduction: https://docs.riverside.fm/quickstart
4.Salesforce editions with API access: https://help.salesforce.com/s/articleView?id=000385436&language=en_US&type=1
5.Intuit: Set up QuickBooks Web Connector: https://quickbooks.intuit.com/learn-support/en-us/help-article/install-products/set-quickbooks-web-connector/L4Vp7VI44_US_en_US
6.Intuit Developer: Get started with QuickBooks Web Connector: https://developer.intuit.com/app/developer/qbdesktop/docs/get-started/get-started-with-quickbooks-web-connector
7.Oracle NetSuite: MCP Standard Tools SuiteApp: https://docs.oracle.com/en/cloud/saas/netsuite/ns-online-help/article_143403258.html
8.Oracle NetSuite: Available Tools in the MCP Standard Tools SuiteApp: https://docs.oracle.com/en/cloud/saas/netsuite/ns-online-help/article_0902023508.html
9.Fulfil: Claude ERP Integration & ChatGPT ERP Integration: https://www.fulfil.io/platform/mcp/
10.Model Context Protocol: What is MCP?: https://modelcontextprotocol.io/docs/2026-07-28/getting-started/intro
11.Model Context Protocol: Tools specification and security considerations: https://modelcontextprotocol.io/specification/2025-06-18/server/tools
12.Model Context Protocol: Resources specification: https://modelcontextprotocol.io/specification/2026-07-28/server/resources
13.Odoo 19.0 documentation: External JSON-2 API: https://www.odoo.com/documentation/19.0/developer/reference/external_api.html
Editorial note: Vendor capabilities and plan access change over time. The examples and citations above were checked against the linked public materials on August 19, 2026. The article intentionally distinguishes first-party support, third-party/community bridges, plan-level gating, and local connector architectures.
If you’re a US based Manufacturer or Distributor and I can help you with your own B2B eCommerce, AI or digital transformation program - pop over to my website and book a no-obligation initial consult HERE.
I also provide advisory services to agencies, platform vendors and investors in the B2B space.
JASON:
Hosts THE ECOMMERCE EDGE Podcast (700+ episodes)
Posts regularly to LinkedIn (34k+ followers)
Is a passionate eCommerce mentor, commentator, keynote speaker and content producer that loves giving back to the industry
Is a member of and regular thought leadership contributor to The B2B eCommerce Association: Jason Greenwood B2BEA Profile
You can find Jason’s full bio HERE
No posts
Comments
Nothing yet. Say the first thing.
Sign in to join the conversation.