Two tools with clear, domain-specific descriptions (ANF encoding). Both have input schemas with required fields and property descriptions. However, schemas lack explicit type declarations for nested objects (e.g., 'view' in anf_encode_kubernetes is type:object but properties are undocumented). Output schemas are completely absent, LLMs cannot predict what these tools return. Parameter descriptions are present but minimal (10-30 chars). No error handling guidance, no examples of success/failure responses, no pagination or result limits documented. Tool names are verb-noun (encode_*) which is good, but descriptions don't explain WHEN to use each tool or how they differ. No tool annotations (readOnlyHint present in metadata but not in schema). Overall: functional but sparse definitions that would require LLM trial-and-error to use effectively.

• Document output schemas for both tools. Example: anf_encode should return {type: 'object', properties: {encoded: {type: 'string', description: 'ANF-encoded output'}, source: {type: 'string'}, scope: {type: 'string'}}}.
• Expand parameter descriptions to 50-200 chars. For 'data' in anf_encode: 'Any JSON value (object, array, string, number, boolean, null) to encode as ANF. Deterministic mapping preserves all fields and structure.'
• Formalize nested object schema for anf_encode_kubernetes. Declare 'view' properties: cluster (string), namespace (string), deployments (array of objects with name, replicas, status), services, jobs, cronjobs, events, agentPermissions.
• Add error handling examples. Document: 'If data is not valid JSON, returns error: "Invalid JSON input". If view lacks required fields, returns error: "Missing required field: cluster".'
• Add tool annotations to schema. Include readOnlyHint: true in both tool definitions to signal to LLMs that these tools do not modify state.

Inferred effective spec: 2026-07-28+.

• Relies on Logging (deprecated) - log to stderr or use OpenTelemetry