17 out of 30 tools have no visible input schema in source code (whoami, analyze_complexity, analyze_satd, analyze_tdg, analyze_cognitive, system_info, polyglot_pipeline, log_stream, api_fetch, full_workflow, get_metrics, get_health, set_component_health, error_test, and others). Tool implementations are inferred from tool names and brief descriptions only.

Parameter descriptions are missing for many tools beyond the Deno examples. Tools like analyze_tdg, system_info, log_stream, api_fetch, full_workflow, get_metrics, get_health, set_component_health lack detailed parameter or return documentation in visible source.

Duplicate tool names 'greet' (appears twice: Deno and Rust versions) violates naming clarity. LLMs cannot distinguish between two tools with identical names. Should be renamed to 'greet_deno' and 'greet_rust' or consolidated.

Generic and vague descriptions: 'Full metrics report' (metrics_summary), 'Complete pipeline' (full_workflow), 'Pipeline using all languages' (polyglot_pipeline) do not explain WHAT these tools return, WHEN to use them, or their dependencies. LLMs cannot reliably choose these tools.

No output schemas documented for any tool. Consumers cannot predict what fields will be returned, breaking tool chaining. E.g., if get_user returns 'user_id', can update_user accept it? Unknown.

REST API proxy tools (get_user, get_repos, search_repos) accept only GitHub usernames but lack documentation on pagination, rate limits, error handling, or required authentication scope.

Destructive tool counter_increment (marked WRITE risk) lacks confirmation/dry-run pattern. No description warns that this modifies state. Agents may call it accidentally.

Tools operating on the same resources use inconsistent naming: 'get_user' and 'get_repos' vs 'get_health' and 'set_component_health'. No clear verb_noun pattern across all tools. This creates cognitive load for LLMs choosing between similar tools.