Three tools with Russian descriptions and basic schemas. direct_status and direct_report have reasonable descriptions (100-150 chars), but direct_call's description is verbose (250+ chars) and mixes concerns. All three tools lack proper parameter descriptions, params are documented at a high level but individual fields lack type info and constraints. No output schemas documented. Error handling is present in code but not surfaced in tool definitions. Tool names lack clear verb-noun structure (direct_call is vague; direct_api_call would be clearer). No tool annotations (readOnlyHint, destructiveHint). Schemas present but incomplete: direct_call and direct_report accept 'object' type params with minimal field documentation, violating the pattern:constrained-input requirement for enums and explicit constraints.

• Rename tools with clear action verbs: 'direct_call' → 'call_direct_api', 'direct_report' → 'get_direct_report', 'direct_status' → 'check_direct_status'.
• Document output schemas for each tool. E.g., direct_call returns {result: object, units: string, requestId: string}; direct_report returns {report: string, rows: number, units: string}.
• Replace generic 'object' params with explicit field schemas. For direct_call.params, document which fields are required/optional based on the service and method (e.g., campaigns.get requires FieldNames, SelectionCriteria is optional).
• Add tool annotations: readOnlyHint=true for direct_status and direct_report; destructiveHint=true for direct_call when method matches MUTATING regex.
• Expand parameter descriptions to include constraints and examples. E.g., 'service (string, required): One of: adextensions, adgroups, ... (see SERVICES list)' and 'method (string, required): API method name (get, add, update, delete, etc.). Mutating methods blocked in readonly mode.'