Single tool 'evaluate' has a clear verb-noun name and basic description. Input schema is present with typed parameters (expression: string, context: object). However, the description is minimal (67 chars, below the 194-char baseline), lacks WHEN/WHY guidance, and omits error recovery hints. Output schema is documented but returns a generic string result rather than structured CEL value details. Parameter descriptions are present but sparse. No mention of CEL syntax constraints, error cases, or common pitfalls. Tool is read-only (good), but lacks idempotent/destructive annotations. Composition is sound (single responsibility), but error handling is generic ('Evaluation failed') without actionable recovery guidance.

• Expand tool description to 100-150 chars: 'Evaluates a CEL expression against a context map. Use this to compute derived values, validate conditions, or transform data. Requires valid CEL syntax; returns the evaluated result with its type.'
• Add parameter descriptions: expression='A valid CEL expression string (e.g., "a + b", "name.startsWith(\"J\")"). See https://github.com/google/cel-spec for syntax.'; context='A JSON object mapping variable names to values available during evaluation (e.g., {"a": 5, "b": 10}).'
• Change output schema from {result: string} to {value: <any>, type: string, error?: string} to preserve type information and enable type-aware chaining.
• Enhance error handling: catch CEL compile errors separately from execution errors; return {error: 'Syntax error in expression', details: '...', retryable: false} vs {error: 'Variable not found: x', retryable: true, suggestion: 'Available variables: a, b, c'}.
• Add tool annotations in rmcp macro: #[tool(description="...", readOnlyHint=true, idempotentHint=true)] to signal safety properties to agents.

Inferred effective spec: <=2025-11-25.

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