Package-level declarations
Types
Host-supplied sink for tools/call audit records. Implementations must be cheap and non-throwing on the calling path — the protocol invokes record synchronously after each call and swallows exceptions so a broken audit backend never fails a tool. The Room-backed implementation lives in the opt-in droid-mcp-audit module; hosts that don't depend on it pay nothing.
Ready-made prompts built on the standard tool modules. Add them with DroidMcp.Builder.addBuiltInPrompts. Each one is listed only while the tools it names are registered and enabled (see McpPrompt.requiredTools), so hosts can add all of them safely.
What a completion (McpPrompt.complete, ResourceProvider.complete) can draw on: the other arguments the user has already filled in, and callTool for reading device data through a read-only tool, e.g. contact names from search_contacts. The server builds the context; the public constructor (no tools, callTool always null) is for testing a completer.
The SDK entry point. Built via DroidMcp.builder / Builder, it owns a ToolRegistry and both transports: an always-on InProcessTransport for on-device LLMs (listTools / callTool) and an optional HttpTransport for desktop MCP clients (startServer).
The answer to an elicit request.
A reusable prompt template a client can offer its user (MCP prompts/list / prompts/get). droid-mcp ships a few in BuiltInPrompts; hosts can add their own via DroidMcp.Builder.addPrompt.
A parameterised family of resources (MCP resources/templates/list), e.g. droidmcp://contacts/{id}. uriTemplate follows RFC 6570.
The contract every droid-mcp tool implements. A tool is a single, self-describing capability — its name, description, and parameters are surfaced verbatim through MCP tools/list, and execute services a tools/call.
Builds the JSON Schema a tool advertises as McpTool.outputSchema, and checks result maps against it.
The JSON Schema primitive type of a ToolParameter. jsonType is the literal string emitted into the tool's inputSchema ("string", "integer", …).
Runtime-permission checks shared by every module's provider object. The SDK never requests permissions (the host app owns its permission UX) — it only inspects what has already been granted, so a tool can decline gracefully.
Uniform shape returned by every special-access module's permissionStatus(context) helper. Lets host apps render permission cards inline (e.g. in chat) before the LLM tries to call a tool, with a single switch over a closed type.
One progress update from a running tool; see reportProgress.
One argument a prompt accepts (MCP prompts/list). Values always arrive as strings.
One message of a rendered prompt. droid-mcp prompts are text-only.
Thread-safe collection of McpPrompts keyed by name, with change listeners like ToolRegistry.
The output of McpPrompt.render: the messages plus an optional description of this rendering.
Supplies resources for one area of the device (photos, files, contacts, …). Registered through DroidMcp.Builder.addResourceProvider; each module exposes its own, e.g. MediaTools.resources(context).
Thread-safe collection of ResourceProviders. Changes are reported to addChangeListener subscribers so the HTTP transport can emit notifications/resources/list_changed; providers whose listing changes on their own call notifyChanged.
Behavioural hints attached to a tool, mirroring the MCP tools/list annotation fields. They are advisory metadata for clients and LLMs — the SDK does not enforce them — but the HTTP transport's readOnly server mode uses readOnlyHint to decide which tools to expose.
One audited tools/call. Captured by McpProtocolImpl after the tool runs and handed to the host's AuditSink.
Host callback that approves or declines a tool call before it runs — typically by showing the user a dialog ("Allow send_message to +1 555…?"). Return true to run the tool.
A tool call waiting for the host's approval. See DroidMcp.Builder.confirmToolCalls.
Thread-safe collection of registered McpTools, keyed by McpTool.name. Backed by a ConcurrentHashMap so tools can be registered and invoked concurrently. Also tracks a host-controlled runtime gate (see setDisabledTools) that hides/blocks tools without unregistering them.
The outcome of an McpTool.execute call. Exactly one of data / errorMessage is meaningful, selected by isSuccess. The protocol layer maps a result onto the MCP tools/call response: success becomes content, failure becomes an isError: true payload.
Properties
Functions
Report progress from inside McpTool.execute. Over MCP this becomes a notifications/progress message when the client asked for progress (it sent a progressToken); in-process callers receive it through the onProgress overload of DroidMcp.callTool. Otherwise it does nothing, so tools can call it unconditionally.