This CLI tool exposes 5 graph encoding/decoding utilities with minimal MCP integration. All tools have basic descriptions (10-50 chars), but parameter schemas are severely underdeveloped. The 'file' parameter appears in all tools with a single-line description; no type constraints, enums, or validation guidance. No output schemas are documented. Error handling is absent, exceptions are caught and printed to stderr with no recovery guidance. The tools themselves are READ_ONLY utilities (safe), but the MCP interface lacks the structure needed for reliable agent integration. Tool names are clear (encode, decode, stats) but descriptions are too terse to guide LLM selection.

• Expand tool descriptions to 80-150 chars. Example: 'encode: Convert a JSON graph payload (with symbols and edges) to GCF (Graph Compact Format) for token-efficient LLM responses. Use this for structured graph data; use encode-generic for arbitrary JSON.'
• Document output schemas for each tool. E.g., encode returns {type: 'string', description: 'GCF-encoded text'}, stats returns {type: 'object', properties: {symbols: number, edges: number, jsonTokens: number, gcfTokens: number, savings: number}}.
• Add parameter constraints: file should have {type: 'string', description: 'Path to input file (JSON or GCF). If omitted, reads from stdin.', minLength: 0, pattern: '^[^\x00]*$'} to prevent null bytes and path traversal.
• Implement error recovery hints. Catch EncodeException and return {error: 'out_of_range', message: 'Integer X is outside int64 range. Model larger values as strings per SPEC 2.3.2.', recovery: 'Retry with string representation of the value.'}
• Clarify the distinction between encode/decode (graph-specific) and encode-generic/decode-generic (arbitrary JSON). Add a discovery tool or resource that lists supported graph types and their schemas.