What happens to documentation when AI becomes the application interface?

There was a post on LinkedIn this week suggesting that users will be able to create their own interfaces using Claude and ChatGPT. They argued software companies should therefore focus on providing an interface that AI systems can use to access their software. One way to do this would be through Model Context Protocol (MCP).

The underlying change would be that software became a collection of capabilities. In this scenario, a software company focuses on supplying reliable operations and data through MCP servers.

This change could have a huge impact on the software sector. It would reduce demand for some UI and UX work, and it would affect Technical Authors too.

Software companies would no longer control every aspect of the interface. If an AI creates the interface dynamically, the familiar menus, buttons, and navigation might not exist. Different users could have entirely different workflows.

It seems unlikely that software companies would want to give up that control entirely. MCP access is therefore more likely to become an additional option than a replacement for the traditional user interface.

Even as an additional option, it would change how people discover and use software.

If the primary reader becomes an AI system, how might documentation change?

The fundamental change would be that documentation is no longer primarily something humans read to learn how to operate software. It becomes part of the software’s operational infrastructure: information AI systems consume to understand what the software can do and how to use it correctly.

An MCP server exposes capabilities that AI systems can discover and invoke.

Example: A financial application

Suppose a financial application exposes a tool called transfer_funds.

A basic parameter reference might tell us:

• source_account is a string.
• destination_account is a string.
• amount is a number.

That describes the inputs, but it leaves important questions unanswered for both developers and AI agents.

The agent also needs to understand:

• When it should use the tool.
• What conditions must be satisfied first.
• Whether the operation is reversible.
• What permissions are required.
• Whether the user must explicitly confirm the transaction.
• What to do when the operation fails.
• How to distinguish similar tools.
• Which assumptions are unsafe.

The documentation influences the behaviour of the AI system operating the software

Tool descriptions, parameter documentation, and error messages become another interface that needs careful technical writing. Much of this work is similar to API documentation, but with greater emphasis on helping an agent select and combine operations.

AWS’s MCP guidance already recommends treating tool descriptions as instructions that guide model decisions. It advises including usage conditions, error cases, and workflow dependencies.

Vague or ambiguous wording could contribute to functional failures. Technical Authors who understand precision, consistency, and audience are in a good position to do this work. And it brings them closer to API design and the instructions that guide AI behaviour.

Poor documentation could cause an AI to choose the wrong tool, misuse a parameter, misunderstand an operation, or perform a workflow incorrectly. The consequences could include failed customer tasks and additional support work.

Documentation quality becomes an operational reliability issue

Documentation cannot enforce permissions or transaction approval, though. Those controls must exist in the software. The documentation needs to explain them accurately.

What becomes less important

UI-centric documentation

Screen-by-screen walkthroughs, “click here, then here” tutorials, and screenshot-heavy guides lose value where the interface is generated and differs between users. But they remain useful for customers working through the product’s own interface.

Feature discovery content

Guides to menus and navigation matter less when users state what they want and an assistant selects the relevant capabilities.

However, the need for discovery remains. Some of that work shifts into descriptions that help the assistant recognise when to use a capability.

Basic how-to articles

People might read fewer simple task instructions when an assistant can complete those tasks for them.

The underlying instructions and rules could still be needed as source material for the assistant.

What becomes more important

Conceptual and domain documentation

The model can call tools, but it still needs to understand the product’s underlying concepts. For example: what an “entitlement” is, how objects relate, and which business rules apply.

Good conceptual content becomes reference material for the model, whether retrieved when needed or included in instructions.

Example: An invoicing platform

An invoicing platform’s MCP server might expose capabilities to create invoices, apply discounts, calculate taxes, issue refunds, and retrieve account balances.

Exposing those operations does not explain the business rules governing them.

For example:

• When can an invoice be cancelled rather than credited?
• What constitutes a finalised accounting period?
• How should partial refunds be handled?
• Which operations require additional authorisation?
• What exceptions apply in different jurisdictions?

These are conceptual questions rather than interface questions. An AI needs reliable answers to work effectively.

Machine-readable structure

Clean, consistent, well-structured content matters because an AI system needs to find and interpret the relevant information.

Structured authoring, metadata, and semantic markup can help make that information easier to retrieve and reuse.

Workflows and recipes

Documenting how tools combine to achieve outcomes fills a gap that individual tool descriptions cannot cover.

For example, onboarding a customer might require a sequence of operations, with checks and decisions between them. The documentation needs to explain that sequence.

Constraints, limits, and exceptions

Permissions, rate limits, destructive actions, and edge cases need to be explicit. An AI acting on a user’s behalf can make consequential changes quickly.

The documentation should explain what is allowed, what requires approval, and when the agent should stop.

Verification and testing

Documentation becomes more testable.

Today, documentation quality is often evaluated through readability, accuracy, feedback, and page analytics. In an environment where agents use the software, it could also be evaluated by observing their behaviour.

Part of the audience is a probabilistic machine. An explanation that is clear to a person might still produce unreliable model behaviour.

Someone has to check whether models use the tools correctly given the documentation. Running test prompts, reviewing failures, and rewriting descriptions become ongoing tasks.

For product and engineering teams, the useful measure is whether the customer’s task was completed correctly.

Counterpoints

Humans still need documentation

Administrators, developers, auditors, and compliance teams will still read documentation directly, especially for security, configuration, and regulated contexts.

Reference documentation remains necessary.

The premise is uncertain

It seem very likely that many companies will retain their own interfaces for complex workflows, collaboration, and brand reasons.

An approach centred on MCP might suit some data-centric or developer-oriented products better than others.

A hybrid, where both routes exist, seems more likely than a universal replacement of traditional interfaces.

Changes to the role

For Cherryleaf, we can offer an MCP and agent-readiness audit alongside our RAG-readiness audit.

The audit reviews tool names, descriptions, parameter documentation, error messages, and server instructions for ambiguity.

Documentation projects for an AI audience will focus more on:

• Workflow and recipe documentation showing how tools combine.
• Permissions, limits, and destructive actions that agents need to understand.
• Regular testing of whether AI models use the tools correctly.

Testing involves running representative prompts against selected assistants, logging failures, and improving the content. Results need to record the model and application versions used.

An MCP documentation audit can provide:

• A readiness scorecard.
• An evaluation report with test prompts, results by assistant, and failure analysis.
• A prioritised fix list ranked by impact on task success and risk, with effort estimates.
• Sample rewrites for representative tool descriptions and one workflow.
• Recommendations for ownership, review triggers, and a regression test set.

Two specialisms?

The role could develop into two specialisms:

• Human-focused technical communication.
• Agent-facing documentation engineering.

Some Technical Authors would work across both.

Some Technical Authors could move towards being “context engineers”: curating the knowledge a model draws on, defining vocabulary, and maintaining the quality of information exposed through tools.

Skills in terminology management, single-sourcing, taxonomy, and content modelling transfer well.

One consequence is that Technical Authors might need a deeper understanding of software architecture than many documentation roles currently require. They would need to understand how agents discover operations, interpret them, and combine them with other operations.

Documentation would become more structured, modular, and machine-readable

Traditional documentation often takes the form of a hierarchy of pages. A documentation system designed for agent use might also be organised around capabilities, entities, operations, constraints, and relationships.

Example: An invoice

For example, information about an invoice could be maintained as structured components:

• Invoice: definition, states, and properties.
• Create invoice: inputs, outputs, and permissions.
• Finalise invoice: prerequisites and consequences.
• Cancel invoice: validity rules and alternatives.
• Refund invoice: dependencies and exceptions.

These components could be used in MCP tool metadata, API documentation, internal knowledge systems, human help content, and automated tests.

This would reinforce the value of structured authoring, content reuse, semantic metadata, and docs-as-code.

Deciding what’s needed

It could also bring documentation architecture closer to software architecture.

Not all documentation should be embedded in MCP tool descriptions. Tool definitions consume context space, so descriptions need to remain focused. AWS’s guidance also notes this context cost.

A more scalable approach could combine concise tool metadata with detailed resources, schemas, and retrievable reference material.

The Technical Author’s task would be to decide what information needs to be available, where it belongs, and when an agent needs it.

Companies might not own the learning experience

Today, a software company controls much of the customer’s experience of learning its product. The company designs the interface, establishes terminology, writes help content, and decides how users discover features.

In this imagined future, much of that experience is mediated by ChatGPT, Claude, or another AI system.

This has several implications:

• Documentation becomes another channel for product discoverability. An agent that cannot understand when to invoke a capability might never use it.
• Product differentiation could depend more heavily on the reliability, completeness, and compatibility of the available capabilities.
• Technical Authors could help products communicate their capabilities to AI systems as well as to human customers.

Good descriptions help, although tool selection also depends on client behaviour, permissions, and agent design.

There is a parallel with search engine optimisation, although the mechanisms are different. Companies could increasingly invest in making their software capabilities understandable and appropriately selectable by AI agents.

For people responsible for product adoption, this introduces another question: can an assistant recognise when your product can fulfil a customer’s request?

A change in the purpose of documentation

The more software interfaces are generated automatically, the more important the underlying descriptions of software behaviour become.

If an interface is no longer fixed, the AI must understand what is possible, what is allowed, and what consequences follow each action. That knowledge must come from somewhere.

The emphasis of documentation work could shift:

These responsibilities would overlap. Human documentation would continue, while more content would support automated use.

Implications for Technical Authors

Technical Authors could move from explaining interfaces to documenting capabilities for both humans and AI agents.

That could increase demand for some skills while reducing demand for others. Structured content, API and tool descriptions, and evaluation of AI behaviour could become a larger part of the work.

For software companies, the practical starting point is to select one customer workflow. Check whether an agent can discover the relevant capabilities, understand the rules, and complete the task correctly.

The results could reveal documentation gaps, tool design problems, or both.

About Cherryleaf

Your software has an API. But can AI agents use it correctly? AI assistants are changing how people interact with software. Tool descriptions, API documentation, and operational rules help determine whether agents can discover and use your product successfully.

Cherryleaf can help software companies assess and improve the information supporting agent use:

• MCP and API documentation audits.
• Agent-facing tool and workflow descriptions.
• Agent usability and reliability evaluations.

Contact us for more details.