AppFunctions: Android’s MCP Layer for the Agentic Era
For the last few years, developers have been asking a simple question:
How do we connect AI to our applications?
The answer increasingly revolves around tools.
A model can understand a request, but to actually do something, it needs a way to interact with software. That is the idea behind the Model Context Protocol (MCP): give AI agents a standard way to discover capabilities and use them as tools.
Now Android is bringing that idea much closer to the operating system.
Its answer is AppFunctions.
Google describes AppFunctions as an Android platform API with a Jetpack library that simplifies Android MCP integration. More importantly, Google explicitly calls AppFunctions the mobile equivalent of tools within MCP and says they allow Android apps to behave like on-device MCP servers.
That makes AppFunctions more interesting than simply being another API.
They are part of Android’s answer to a much bigger question:
How should AI agents interact with Android apps?
From opening apps to using capabilities
The traditional smartphone model is built around applications.
You want to create a task, so you open a Todo app.
You want to send a message, so you open a messaging app.
You want to play something, so you open a music app.
The application is the destination.
Agentic computing changes that model.
You might instead say:
“Create a task to review the Android release tomorrow.”
The important thing is no longer which application you open. The important thing is that the system can find a capability that can create that task.
That is exactly the direction Android is moving toward with AppFunctions.
Google’s own AppFunctions samples demonstrate app capabilities being exposed to Android intelligence features and agents. The current official sample even includes a chat application exposing actions such as sending messages, searching contacts, and initiating calls.
The app becomes less of a destination and more of a capability provider.
MCP gave AI a toolbox. AppFunctions bring that toolbox to Android.
MCP provides a common way for AI systems to work with tools.
At a high level:
AI agent → tools → applications and services
Android is taking that concept and moving it into the phone:
AI agent → Android intelligence system → AppFunctions → Android app
The distinction matters.
A traditional MCP setup may involve a remote server somewhere on the internet.
AppFunctions are designed around the Android environment. The application’s functions can be made available through the Android OS’s own registry, enabling agents and assistants to use them on-device.
So instead of every developer asking:
“How do I build an MCP server for my Android app?”
Android is effectively saying:
“Expose the capabilities of your app as AppFunctions, and Android can make them available to the agent ecosystem.”
Your app becomes an on-device tool
Imagine a Todo app.
Today, it may look like this:
User → Todo UI → Task
With AppFunctions, there is another path:
User → AI agent → AppFunction → Task
The Todo app is still there.
Its UI is still there.
Its database is still there.
But now the application also exposes a machine-readable capability that an agent can use.
This is the fundamental shift.
An Android app is no longer only something a person interacts with. It can also become something an agent calls.
This is bigger than AI chat inside an app
There is a subtle but important difference between adding AI to an app and making an app agent-accessible.
An AI feature inside your Todo app might help the user rewrite a task.
An AppFunction can allow an external agent to actually create the task.
Those are two very different ideas.
One puts AI inside the application.
The other makes the application part of the AI’s toolbox.
Android’s current direction is clearly toward the second model. Google describes AppFunctions as a mechanism for applications to contribute services, data, and actions to the Android OS registry so that agents and system-level experiences can use them.
The developer decides what becomes a tool
This doesn’t mean AI gets unrestricted access to your app.
That’s one of the most important aspects of the model.
A developer decides which capabilities are exposed.
For example, a Todo application might choose to make these available:
Create task
Find task
Update task
Complete task
The rest of the application’s internal behavior can remain internal.
This creates a much cleaner boundary:
The app decides what it is willing to do for an agent.
Android also has permissions around AppFunction discovery and execution, reinforcing the idea that this is controlled capability exposure rather than unrestricted application access.
Why local matters
One of the most interesting parts of Android’s approach is that AppFunctions are designed for on-device use.
That changes the architecture.
Consider two approaches.
Remote MCP
Agent → Internet → MCP server → backend
AppFunctions
Agent → Android → AppFunction → app
Remote MCP is still valuable. If you are building a service that needs to work across Android, web, desktop, and other platforms, a remote MCP server can make sense.
But AppFunctions are specifically designed to make Android applications first-class participants in the local agent ecosystem.
Google describes remote MCP and AppFunctions as complementary rather than competing approaches.
The real innovation is the registry
The most interesting architectural piece may not actually be the function itself.
It is the OS-level registry.
An application can contribute functions to the registry.
An agent can discover available capabilities.
The system can then connect the user’s request to an appropriate application function.
That creates an ecosystem where applications don’t have to know in advance which AI will call them.
They simply describe the capabilities they provide.
This is very close to the promise of MCP:
Standardize the connection between intelligence and tools.
Android is essentially adapting that promise to the mobile operating system.
This changes how Android developers design APIs
For years, developers have primarily designed APIs for other developers.
Then APIs became important for web services.
Now we have another consumer:
AI agents.
That changes what makes an interface good.
An agent needs to understand:
- What a capability does
- When it should be used
- What information it needs
- What it returns
- What limitations apply
Android’s AppFunctions tooling puts unusual emphasis on function descriptions and KDoc because that information helps agents understand how to use the exposed capability correctly. Google’s current AppFunctions guidance even includes dedicated tooling for refining these descriptions for agent use.
So documentation is becoming part of the interface between your app and AI.
Android is already demonstrating the pattern
This is not only a theoretical architecture.
Google’s current AppFunctions sample repository includes a functional ChatApp that exposes application capabilities to the Android intelligence system. The sample demonstrates capabilities including sending messages, searching contacts, and initiating calls, across mobile and Wear OS.
Google also published a July 2026 tutorial showing how an existing Android application can be integrated into Android’s intelligence system using AppFunctions as part of its broader “Build intelligent Android apps” series.
The direction is therefore becoming concrete:
Apps expose capabilities.
Android indexes those capabilities.
Agents discover them.
The system uses them to complete tasks.
AppFunctions are not “just another MCP library”
This is where the terminology can become confusing.
AppFunctions are not simply Android’s implementation of a generic MCP server that you deploy somewhere.
They are an Android-native abstraction for making application capabilities available to the system and to agents.
That is why Google’s terminology is important.
It doesn’t merely say AppFunctions “work with MCP.”
It says AppFunctions are the mobile equivalent of MCP tools and enable apps to behave like on-device MCP servers.
That is a much bigger statement.
It positions AppFunctions as part of Android’s architecture for agentic computing.
The operating system becomes the connector
There was a time when the operating system mainly connected users to applications.
Now the operating system can also connect agents to applications.
That creates a new layer:
User
↓
Agent
↓
Android intelligence system
↓
AppFunctions
↓
Applications
↓
Data and actions
This is potentially one of the most important changes coming to Android application architecture.
Instead of every AI integration being a one-off partnership between an app and an assistant, the OS can provide a common mechanism for discovering application capabilities.
What this means for app developers
The question is no longer only:
“What features should my app have?”
A new question is emerging:
“What capabilities should my app expose to an agent?”
That could be task creation in a productivity app.
Messaging actions in a communication app.
Playback controls in a media app.
Search in a knowledge app.
Actions in a travel app.
The possibilities are much broader than any one example.
The important design principle is to expose meaningful user capabilities, not random internal methods.
An agent should see:
“Create a task.”
Not:
“Call this internal database function.”
The closer the exposed capability is to a real user goal, the more useful it becomes in an agentic system.
There is still a long way to go
AppFunctions are currently in experimental preview, so this is an evolving platform rather than a finished Android contract. Google’s documentation says AppFunctions are available from Android 16 onward, and Gemini integration was still in private preview with trusted testers as of May 2026.
The ecosystem is also actively developing. Google’s official AppFunctions repository continues to evolve, with current samples and a testing agent for evaluating AppFunction integrations.
That makes this an interesting moment for Android developers.
The standards are forming.
The platform support is arriving.
And the application model is beginning to change.
The bigger picture
MCP asks:
How can AI use tools?
Android AppFunctions ask a more specific question:
How can AI use the capabilities already living inside Android apps?
That is the real story.
AppFunctions are not about adding a chat box to your application.
They are about making your application legible to an agent.
Your app can continue to serve people through screens and buttons.
But it can also expose a set of capabilities that intelligent systems can discover and orchestrate.
That is the beginning of an agent-ready Android application.
Final thought
The first generation of mobile apps was designed for fingers.
The next generation is being designed for intent.
Instead of:
“Open the app and do this.”
The experience moves toward:
“I want this done.”
MCP provides the broader language of tools for AI.
And AppFunctions provide Android’s native bridge between those agents and the capabilities inside applications.
That may ultimately be the most important way to think about AppFunctions:
They turn Android apps from destinations into tools.
And once your app can become a tool, the AI doesn’t need to ask the user which app to open.
It can simply get the right thing done.