The Android Source Explorer MCP Server provides on-demand access to AOSP and AndroidX source code, giving AI tools precise access to real Android framework internals for advanced code exploration.
Search for classes by glob pattern or substring (e.g., *ViewModel* or Activity) across the synced source tree
Retrieve full class source code for any Android Framework or AndroidX class
Look up a specific method's source code within a class, including its Javadoc and annotations
List all method and field signatures (members) of a given class
Get the inheritance hierarchy (superclass and implemented interfaces) for any class
Search for text or regex patterns within a specific class or across all synced source files
List available versions of an AndroidX artifact (e.g., androidx.compose.runtime:runtime)
Check the integrity of the local source cache and index
Go to definition of a symbol at a specific line/character position (requires LSP)
Find all references to a symbol across the entire source tree (requires LSP)
Get type information and documentation (hover data) for a symbol (requires LSP)
The server uses a hybrid architecture combining Tree-sitter for fast single-file parsing with optional LSP engines for cross-file intelligence, and operates offline via a local cache of synced sources.
Enables on-demand, precise exploration of the Android Open Source Project (AOSP) and Jetpack (AndroidX) libraries, allowing for class searches, method body extraction, and analysis of framework internals like lifecycle management and Compose.
Syncs source code and library artifacts directly from Google-hosted infrastructure, including the Android Open Source Project (AOSP) repositories and the Google Maven repository.
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@Android Source Explorer MCP Server show me the implementation of the onCreate method in Activity.java"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
MCP server for exploring AOSP internals and Jetpack libraries.
When building Android applications, AI tools often rely on outdated training data or incomplete summaries of the Android Framework. This MCP server provides on-demand, precise access to the actual source code (AOSP and AndroidX), enabling the AI to understand complex framework internals like the Activity lifecycle, ViewModel restoration, or Compose internals directly from the truth.
Related MCP server: Sigil MCP Server
uv (Recommended) or Python 3.11+
Git
The easiest way to install and keep android-source-explorer up to date is using uv. It handles dependencies (including native ones like Tree-sitter and Cryptography) reliably across platforms.
uv tool install git+https://github.com/mrmike/android-source-explorer-mcpThis will make the android-source-explorer command available globally in your PATH.
After installation, you need to perform an initial sync to fetch the Android source code:
# Sync API 36 (Android 16) and common AndroidX packages
android-source-explorer sync --api-level 36 --androidx "compose,lifecycle,activity"
# (Optional) Download LSP servers for cross-file features
android-source-explorer sync --lspCheck sync status:
android-source-explorer statusTo check for and download the latest available Android Framework revisions (AOSP tags) and newer stable versions of your synced AndroidX packages, run:
# Update all synced framework APIs and AndroidX packages, then rebuild the index
android-source-explorer update
# (Optional) Clean up older versions of updated AndroidX packages
android-source-explorer update --clean
# Update only a specific API level or AndroidX package
android-source-explorer update --api-level 36
android-source-explorer update --androidx activity-composeAdd the MCP server to your configuration file (e.g., Claude Desktop, Cursor, Gemini CLI).
If installed via uv tool install, the tool is available globally.
Basic Setup:
{
"mcpServers": {
"android-sources": {
"command": "android-source-explorer",
"args": ["serve"]
}
}
}With LSP Features Enabled:
{
"mcpServers": {
"android-sources": {
"command": "android-source-explorer",
"args": ["serve"],
"env": {
"ANDROID_SOURCE_LSP": "true"
}
}
}
}If you cloned the repository and want to run it from the source:
{
"mcpServers": {
"android-sources": {
"command": "uv",
"args": ["run", "--directory", "/absolute/path/to/android-source-explorer", "android-source-explorer", "serve"]
}
}
}The server uses a dual-engine approach to balance speed and intelligence:
Tree-sitter (Surgical Engine): Provides near-instant (sub-10ms) AST parsing of single files. It precisely extracts method bodies (including Javadoc and annotations), class members, and inheritance hierarchies without the overhead of a full compiler.
LSP (Global Engine): Optionally leverages the Eclipse JDT LS (Java) and Kotlin Language Server for cross-file navigation. This enables finding references across millions of lines of code and resolving types that span multiple libraries.
To ensure all lookups are instant and offline-ready, the server uses a sync or update command to manage sources in a local cache (~/.android-sources/):
AOSP: Fetches framework sources directly from android.googlesource.com using git sparse-checkouts.
AndroidX: Downloads -sources.jar files from the Google Maven repository (dl.google.com/dl/android/maven2/).
Hybrid Indexing: Prioritizes your local $ANDROID_HOME sources if available, supplemented by the downloaded cache.
Automatic Updates: The update command queries remote endpoints (AOSP Git tags & Google Maven indexes) for updates, downloads newer revisions/versions, and rebuilds the class index.
Tool | Engine | Description |
| Index | Search for classes by glob pattern or substring. |
| FS | Retrieve the full source code for a specific class. |
| Tree-sitter | Extract a precise method body + its Javadoc/annotations. |
| Tree-sitter | List all method and field signatures in a class. |
| Tree-sitter | Get the inheritance chain (superclass + interfaces). |
| FS/Regex | Search for text/regex across the entire source tree. |
| LSP | Resolve the cross-file definition of a symbol. |
| LSP | Find all usages of a class/method across the whole tree. |
| LSP | Get documentation and type info via hover data. |
*Requires ANDROID_SOURCE_LSP=true
Apache License 2.0
Check the integrity of the local source cache and index.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states what the tool does but doesn't describe how it behaves—e.g., whether it's read-only, if it modifies data, its performance characteristics, or error handling. For a tool with zero annotation coverage, this lack of behavioral context is a notable shortfall.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that directly states the tool's purpose without any wasted words. It's appropriately sized and front-loaded, making it easy for an agent to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (simple integrity check), lack of annotations, and presence of an output schema, the description is minimally adequate. It states the purpose but misses behavioral details and usage context. The output schema likely covers return values, so the description doesn't need to explain those, but overall completeness is limited.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has 0 parameters, and the schema description coverage is 100%, so there are no parameters to document. The description doesn't need to add parameter semantics, and it doesn't introduce any confusion. A baseline of 4 is appropriate for a parameterless tool with complete schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('check') and target ('integrity of the local source cache and index'), providing a specific verb+resource combination. However, it doesn't differentiate this tool from its siblings (like 'list_available_versions' or 'search_in_source'), which might also involve cache/index operations, so it doesn't reach the highest score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites, context, or exclusions, leaving the agent to infer usage based on the purpose alone. This is a significant gap for effective tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Find all references to a symbol at a specific position (Requires LSP).
| Name | Required | Description | Default |
|---|---|---|---|
| class_name | Yes | ||
| line | Yes | ||
| character | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions 'Requires LSP', adding some context about dependencies, but fails to describe key traits like whether it's read-only, potential side effects, error handling, or output format. This leaves significant gaps for a tool that likely interacts with code analysis.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with a single, front-loaded sentence that states the purpose and a key prerequisite. There is no wasted verbiage, making it efficient and easy to parse, though it may be overly brief for completeness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (3 required parameters, no annotations, but has an output schema), the description is incomplete. It covers the basic action and a prerequisite but misses details on parameter usage, behavioral traits, and how it differs from siblings. The presence of an output schema mitigates the need to explain return values, but overall, it's minimally adequate with clear gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the schema provides no parameter descriptions. The description adds no semantic details about the parameters (class_name, line, character), such as their roles in locating the symbol or format expectations. It fails to compensate for the lack of schema documentation, leaving parameters largely unexplained.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Find' and the resource 'references to a symbol', specifying the action and target. It distinguishes from siblings by mentioning 'at a specific position' and 'Requires LSP', which hints at context, though it doesn't explicitly differentiate from tools like 'search_classes' or 'lookup_method'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides minimal guidance with 'Requires LSP', implying a prerequisite, but offers no explicit when-to-use rules, alternatives (e.g., vs. 'search_in_source'), or exclusions. It lacks context on when this tool is preferred over other reference or search-related siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the inheritance hierarchy (superclass and interfaces) for a class.
| Name | Required | Description | Default |
|---|---|---|---|
| class_name | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. While it states what the tool returns (inheritance hierarchy), it doesn't describe important behavioral aspects like error handling, performance characteristics, whether it requires specific permissions, or what format the hierarchy information is returned in.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence that efficiently conveys the core purpose without any wasted words. It's appropriately sized for a tool with one parameter and clear output schema.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that there's an output schema (which should document the return format), the description doesn't need to explain return values. However, for a tool with no annotations and 0% schema description coverage, the description should do more to explain behavioral aspects and parameter usage. It's minimally adequate but leaves gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds no parameter information beyond what's in the schema. With 0% schema description coverage and only one parameter ('class_name'), the description doesn't compensate by explaining what format the class name should be in (fully qualified name, simple name, etc.) or providing examples. The baseline is 3 since there's only one parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose with a specific verb ('Get') and resource ('inheritance hierarchy for a class'), making it easy to understand what it does. However, it doesn't explicitly differentiate from sibling tools like 'get_type_info' or 'lookup_class', which might also provide related information about classes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. With sibling tools like 'get_type_info', 'lookup_class', and 'list_class_members' available, there's no indication of when this specific hierarchy-focused tool is preferred over those other options.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get type information and documentation (hover) for a symbol (Requires LSP).
| Name | Required | Description | Default |
|---|---|---|---|
| class_name | Yes | ||
| line | Yes | ||
| character | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It mentions 'Requires LSP', hinting at a dependency, but doesn't disclose other behavioral traits such as what the output looks like, error conditions, or performance implications. For a tool with no annotations, this leaves significant gaps in understanding its behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the core purpose and includes a necessary prerequisite. Every word earns its place, with no wasted text, making it highly concise and well-structured for quick comprehension.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has an output schema (which should cover return values), the description's main gap is in parameter semantics and behavioral transparency. It's minimally adequate for a simple query tool but lacks details on when to use it versus siblings and deeper behavioral context, making it incomplete for optimal agent usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the schema provides no parameter descriptions. The description doesn't add any meaning to the parameters (class_name, line, character) beyond what's implied by the tool's purpose. It fails to explain what these inputs represent or how they should be used, leaving them largely undocumented.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Get' and the resource 'type information and documentation (hover) for a symbol', making the purpose specific and understandable. However, it doesn't explicitly distinguish this tool from siblings like 'lookup_class' or 'lookup_method', which might provide similar information, so it misses full differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description includes a prerequisite note '(Requires LSP)', which provides some context, but it doesn't offer guidance on when to use this tool versus alternatives like 'lookup_class' or 'search_classes'. There's no mention of specific scenarios or exclusions, leaving usage unclear relative to siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Resolve the definition of a symbol at a specific position (Requires LSP).
| Name | Required | Description | Default |
|---|---|---|---|
| class_name | Yes | ||
| line | Yes | ||
| character | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It mentions 'Requires LSP', which adds some context about prerequisites, but it does not describe what the tool returns, error conditions, or any behavioral traits like performance or limitations. This leaves significant gaps for a tool with no annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with no wasted words. It is front-loaded with the core purpose and includes a necessary contextual note, making it appropriately sized and structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that there is an output schema (which should handle return values), the description does not need to explain outputs. However, with no annotations, 3 undocumented parameters, and a purpose that involves resolving symbols, the description is incomplete as it lacks details on behavior, parameter meanings, and usage context beyond the LSP note.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the schema provides no parameter descriptions. The description does not explain what 'class_name', 'line', or 'character' mean in this context, nor does it add any semantic details beyond the schema. With 3 undocumented parameters, the description fails to compensate for the lack of schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Resolve' and the resource 'definition of a symbol at a specific position', making the purpose understandable. However, it does not explicitly distinguish this tool from sibling tools like 'lookup_class' or 'lookup_method', which might serve similar purposes, so it misses full differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description includes a contextual note '(Requires LSP)', which implies usage depends on Language Server Protocol availability, but it does not provide explicit guidance on when to use this tool versus alternatives such as 'find_references' or 'lookup_class'. The usage is implied rather than clearly defined.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List available versions for an AndroidX artifact (e.g. 'androidx.compose.runtime:runtime').
| Name | Required | Description | Default |
|---|---|---|---|
| artifact | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It states the action ('List available versions') but lacks behavioral details such as whether this is a read-only operation, if it requires authentication, rate limits, or what the output format entails. The description is minimal and doesn't disclose key traits beyond the basic purpose.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the purpose with an example. There is no wasted text, making it highly concise and well-structured for quick comprehension.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity (1 parameter) and the presence of an output schema (which handles return values), the description is somewhat complete for its basic function. However, without annotations and with minimal parameter guidance, it lacks depth for safe and effective use, making it adequate but with clear gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 0%, so the description must compensate. It adds meaning by specifying the parameter as an 'AndroidX artifact' with an example, but doesn't explain the artifact format, constraints, or if it's required. With 1 parameter and low coverage, this provides only basic context, insufficient for full understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('List') and resource ('available versions for an AndroidX artifact'), with a specific example provided ('androidx.compose.runtime:runtime'). However, it doesn't explicitly differentiate from sibling tools like 'lookup_class' or 'search_classes' that might also involve artifact information, though the focus on versions is distinct.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. The description implies usage for AndroidX artifacts but doesn't specify prerequisites, exclusions, or compare it to siblings like 'check_integrity' or 'find_references' that might relate to artifacts. This leaves the agent without context for tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all method and field signatures for a given class.
| Name | Required | Description | Default |
|---|---|---|---|
| class_name | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the action ('List all method and field signatures') but doesn't describe traits like whether it's read-only, if it requires specific permissions, how it handles errors, or the format of the output. This is a significant gap for a tool with no annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that directly states the tool's purpose without any wasted words. It's appropriately sized and front-loaded, making it easy for an agent to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity (1 parameter, no nested objects) and the presence of an output schema (which handles return values), the description is reasonably complete for its core function. However, the lack of behavioral details and usage guidelines prevents a perfect score, as these gaps could hinder correct tool selection.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 1 parameter with 0% description coverage, so the schema provides no semantic information. The description adds value by specifying that the parameter is for a 'given class', but it doesn't clarify the expected format (e.g., fully qualified name) or constraints. This partial compensation aligns with the baseline when schema coverage is low.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('List') and resource ('method and field signatures for a given class'), making the purpose specific and understandable. However, it doesn't explicitly differentiate from sibling tools like 'lookup_class' or 'get_type_info', which might also provide class information, so it doesn't reach the highest score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. With siblings like 'lookup_class', 'get_type_info', and 'search_classes', there's no indication of context, prerequisites, or exclusions, leaving the agent to guess based on tool names alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Retrieve the full source code for a given Android Framework or AndroidX class.
| Name | Required | Description | Default |
|---|---|---|---|
| class_name | Yes | ||
| max_lines | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states the tool retrieves source code but omits critical details such as rate limits, authentication needs, error handling (e.g., for non-existent classes), or whether the retrieval is cached. This leaves significant gaps in understanding how the tool behaves operationally.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that efficiently conveys the core purpose without any wasted words. It is appropriately sized for the tool's complexity, making it easy for an agent to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (2 parameters, no annotations, but with an output schema), the description is minimally adequate. It covers the basic purpose but lacks usage guidelines, detailed parameter semantics, and behavioral context. The presence of an output schema mitigates the need to explain return values, but overall completeness is limited.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description implies the 'class_name' parameter specifies the target class but adds no meaning beyond what the input schema provides (e.g., format examples or scope). With 0% schema description coverage, it partially compensates by hinting at the parameter's role, but the 'max_lines' parameter is entirely undocumented in both schema and description, limiting overall effectiveness.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('Retrieve') and target resource ('full source code for a given Android Framework or AndroidX class'), distinguishing it from siblings like 'get_class_hierarchy' (structure) or 'search_classes' (searching). It precisely defines what the tool does without being vague or tautological.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like 'search_in_source' or 'list_class_members'. It lacks explicit context, exclusions, or prerequisites, leaving the agent to infer usage based solely on the purpose statement.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Look up a specific method's source code within a class.
| Name | Required | Description | Default |
|---|---|---|---|
| class_name | Yes | ||
| method_name | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions looking up 'source code', which implies a read-only operation, but doesn't specify whether this requires authentication, has rate limits, returns partial/full code, or handles errors. For a tool with zero annotation coverage, this leaves significant behavioral gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the core purpose without unnecessary words. Every part of the sentence contributes directly to understanding the tool's function, making it appropriately concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity (two simple string parameters) and the presence of an output schema (which likely describes the return value), the description is reasonably complete for its purpose. However, it lacks behavioral context (e.g., error handling, permissions) that would be helpful since no annotations are provided.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds no parameter semantics beyond what the input schema provides—it doesn't explain what 'class_name' or 'method_name' should contain (e.g., fully qualified names, case sensitivity). With 0% schema description coverage and two required parameters, the baseline is 3 since the schema defines the parameters but the description doesn't compensate with additional context.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'look up' and the resource 'a specific method's source code within a class', making the purpose immediately understandable. However, it doesn't explicitly differentiate from sibling tools like 'lookup_class' or 'list_class_members', which could cause confusion about when to use each.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like 'lookup_class', 'list_class_members', or 'goto_definition'. It states what the tool does but offers no context about appropriate use cases or exclusions, leaving the agent to infer usage from the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search for classes by glob pattern or substring (e.g. 'ViewModel' or 'Activity').
| Name | Required | Description | Default |
|---|---|---|---|
| pattern | Yes | ||
| limit | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. While it mentions the search functionality and provides examples of pattern formats, it doesn't describe important behavioral aspects like whether the search is case-sensitive, what happens when no matches are found, whether results are paginated, or what the output format looks like. The description provides basic operational context but lacks critical behavioral details.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise - a single sentence that efficiently communicates the core functionality with helpful examples. Every word earns its place, and the structure is front-loaded with the essential information about what the tool does and how to use the pattern parameter.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that there's an output schema (which should document return values), the description doesn't need to explain output format. However, for a search tool with 2 parameters (one completely undocumented in the description), no annotations, and multiple similar sibling tools, the description provides only basic operational context. It covers the core search functionality but leaves significant gaps in parameter documentation and usage guidance relative to alternatives.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the schema provides no parameter documentation. The description adds value by explaining that the 'pattern' parameter accepts glob patterns or substrings with examples ('*ViewModel*' or 'Activity'), which clarifies the expected input format. However, it doesn't mention the 'limit' parameter at all, leaving half of the parameters undocumented in both schema and description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose as searching for classes using glob patterns or substrings, which is a specific verb+resource combination. However, it doesn't explicitly distinguish this tool from sibling tools like 'lookup_class' or 'search_in_source', which appear to have related functionality.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. With multiple sibling tools that appear related to class searching and lookup (lookup_class, search_in_source, find_references), the description offers no context about when this specific search approach is appropriate versus other available options.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search for a text/regex pattern within a specific class or across all synced files (if class_name is omitted).
| Name | Required | Description | Default |
|---|---|---|---|
| pattern | Yes | ||
| class_name | No | ||
| limit | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It mentions the search scope but doesn't describe important behavioral aspects like: whether this is a read-only operation, what format the results take, whether there are rate limits, what happens with large result sets, or how regex patterns are interpreted. The description is insufficient for a tool with 3 parameters and no annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise - a single sentence that efficiently communicates the core functionality. It's front-loaded with the main purpose and includes the key conditional behavior. There's zero wasted language or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 3 parameters with 0% schema coverage but does have an output schema, the description is minimally adequate. The output schema will document return values, reducing the burden on the description. However, for a search tool with regex capabilities and class filtering, the description should provide more context about search behavior, result format, and limitations to be truly complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description must compensate but adds minimal parameter semantics. It explains the conditional behavior of class_name (search within class vs all files when omitted) but doesn't clarify what 'pattern' expects (simple text vs regex syntax), what 'limit' controls (result count vs something else), or provide examples. The description doesn't adequately compensate for the schema's lack of descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: searching for text/regex patterns within source files. It specifies the resource (synced files) and scope (specific class or all files). However, it doesn't explicitly distinguish this from sibling search tools like 'search_classes', leaving some ambiguity about when to use each.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides some usage guidance by explaining what happens when class_name is omitted (search across all files) versus when it's provided (search within specific class). However, it doesn't offer explicit when-to-use guidance compared to alternatives like 'search_classes' or 'find_references', nor does it mention any prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
v0.1.0check_integrityfind_referencesget_class_hierarchyget_type_infogoto_definitionlist_available_versionslist_class_memberslookup_classlookup_methodsearch_classessearch_in_sourceMost tools have distinct purposes, but there is some overlap between 'lookup_class' and 'lookup_method' as both retrieve source code, which could cause mild confusion. The LSP-based tools ('find_references', 'get_type_info', 'goto_definition') are clearly differentiated, and other tools like 'search_classes' and 'search_in_source' serve unique functions.
All tool names follow a consistent snake_case pattern with clear verb_noun structures (e.g., 'list_available_versions', 'get_class_hierarchy', 'search_classes'). There are no deviations in naming conventions, making the set predictable and easy to understand.
With 11 tools, the count is well-scoped for exploring Android source code, covering tasks from integrity checks to LSP operations and searches. Each tool appears to serve a specific, necessary function without bloat or redundancy, fitting the server's purpose effectively.
The toolset provides comprehensive coverage for source exploration, including search, lookup, LSP features, and version management. A minor gap exists in update or modification tools (e.g., no 'edit_source' or 'apply_patch'), but this is reasonable for a read-only explorer, and agents can work around it.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Code intelligence for coding agents: semantic, AST, graph, and full-text search. 279+ languages.
Code intelligence platform for AI agents. 20 tools for architecture, security & impact analysis.
Codebase intelligence for agents: 152 structured artifacts across 21 programs, one call.
Provide your AI coding tools with token-efficient access to up-to-date technical documentation for…
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/mrmike/android-source-explorer-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
