Loading ToolBench
Android source code search for AI agents: a fast, token-efficient MCP server for cs.android.com
Four well-named, read-only tools with clear descriptions and comprehensive input schemas using Zod validation. All tools follow verb_noun naming (search_, get_, suggest_, list_). Descriptions are detailed (150 - 250 chars) and explain WHAT, WHEN, and HOW. Input schemas are fully typed with enums, ranges, and constraints. However, output schemas are not documented, LLMs cannot predict response structure for planning. Error handling returns generic error text without recovery guidance. Tool annotations correctly declare readOnlyHint=true, but no destructiveHint or idempotentHint present (appropriate for read-only tools). Missing: output schema documentation, actionable error messages, and per-parameter examples in descriptions.
Read a source file from an Android repository with line numbers. Use the project, repository, and branch values exactly as shown in search_android_code results. Large files are paged 2000 lines at a time; use startLine/endLine to read a range.
List the Android source projects available on cs.android.com. Instant and static.
Search code across Android source repositories on cs.android.com. Supports regex and operators: file:<path-regex>, class:<name>, function:<name>, symbol:<name>, lang:<language>, content:<regex>, plus AND/OR and - (negation). Returns matching files with line-numbered snippets. If nothing matches, try suggest_symbols to resolve the exact symbol name. Paginate with pageToken from a previous result.
Autocomplete classes, methods, and files from a partial name. Useful to resolve exact symbol names and their defining files before searching or reading.
Output schemas not documented. LLMs cannot predict response structure (fields, types, pagination tokens) for downstream planning. search_android_code returns 'nextPageToken' but LLMs must infer its type and usage.
Error handling returns generic error text without recovery guidance. errorResult() wraps errors in 'Error: <message>' but does not suggest next steps (e.g., 'Try suggest_symbols() to resolve the exact symbol name').
list_projects has empty inputSchema ({}). While correct for a no-argument tool, the description should explicitly state 'No parameters required' to avoid LLM confusion.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | C | 64 | 2025-06-18+ | v2 |
Parameter descriptions include example values (e.g., 'e.g. "ActivityMan"', 'e.g. "main", "android-latest-release"'). LLMs tend to reuse examples literally rather than adapting to context. Use enum constraints or format declarations instead.
search_android_code's 'responseFormat' enum lacks description of what 'concise' vs 'detailed' actually return (field counts, snippet counts, etc.). LLMs cannot choose the right format without knowing the output difference.