Android Source Explorer MCP Server

by mrmike

Overview Schema Related Servers Score Discussions

Python

Local

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v0.1.0
Disambiguation4/5
Most 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.
Naming Consistency5/5
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.
Tool Count5/5
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.
Completeness4/5
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.
Average 3.1/5 across 11 of 11 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 1 commit in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
This repository is licensed under Apache 2.0.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior2/5
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.
Conciseness5/5
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.
Completeness3/5
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.
Parameters2/5
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.
Purpose4/5
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.
Usage Guidelines2/5
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.
Behavior2/5
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.
Conciseness5/5
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.
Completeness3/5
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.
Parameters2/5
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.
Purpose4/5
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.
Usage Guidelines2/5
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.
Behavior2/5
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.
Conciseness5/5
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.
Completeness3/5
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.
Parameters2/5
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.
Purpose4/5
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.
Usage Guidelines2/5
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.
Behavior2/5
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.
Conciseness5/5
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.
Completeness3/5
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.
Parameters3/5
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.
Purpose4/5
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.
Usage Guidelines2/5
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.
Behavior2/5
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.
Conciseness5/5
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.
Completeness3/5
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.
Parameters2/5
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.
Purpose4/5
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.
Usage Guidelines3/5
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.
Behavior2/5
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.
Conciseness5/5
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.
Completeness3/5
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.
Parameters3/5
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.
Purpose4/5
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.
Usage Guidelines2/5
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.
Behavior2/5
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.
Conciseness5/5
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.
Completeness3/5
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.
Parameters2/5
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.
Purpose4/5
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.
Usage Guidelines3/5
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.
Behavior2/5
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.
Conciseness5/5
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.
Completeness3/5
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.
Parameters4/5
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.
Purpose4/5
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.
Usage Guidelines2/5
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.
Behavior2/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters3/5
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.
Purpose4/5
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.
Usage Guidelines2/5
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.
Behavior2/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters3/5
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.
Purpose4/5
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.
Usage Guidelines2/5
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.
Behavior2/5
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.
Conciseness5/5
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.
Completeness3/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines2/5
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.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![android-source-explorer-mcp MCP server](https://glama.ai/mcp/servers/mrmike/android-source-explorer-mcp/badges/card.svg)](https://glama.ai/mcp/servers/mrmike/android-source-explorer-mcp)

Score Badge

Copy to your README.md:

[![android-source-explorer-mcp MCP server](https://glama.ai/mcp/servers/mrmike/android-source-explorer-mcp/badges/score.svg)](https://glama.ai/mcp/servers/mrmike/android-source-explorer-mcp)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

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