Single tool 'analyze_prompt' has a clear, descriptive docstring (194 chars) and well-documented parameters with types. Input schema is visible and properly typed (prompt: string, session_id: optional string). However, output schema is not documented, the tool returns result.to_dict() but the LLM has no visibility into what fields that dict contains (risk_score, decision, categories, evidence are mentioned in the docstring but not formally specified). Parameter descriptions are good (72+ chars each), explaining the session_id's stateful behavior. No enum constraints, no pagination, no error handling guidance. Tool naming is clear (analyze_prompt) and follows verb_noun convention. Overall solid for a single-purpose security tool, but lacks output schema documentation and error recovery patterns.

• Document the output schema explicitly: define risk_score (float 0-1), decision (enum: ALLOW|BLOCK|WARN), categories (list of strings), evidence (dict with layer-specific findings). Use JSON Schema or a Pydantic model visible in the docstring.
• Add error handling guidance: 'If analysis fails, the engine may be uninitialized (rare) or the prompt may be malformed. Retry with a shorter prompt or contact support.' Include specific error codes/messages the LLM should expect.
• Constrain the prompt parameter: add max length (e.g., 100,000 chars), encoding (UTF-8), and note that extremely long prompts may timeout (~24ms baseline). Document timeout behavior.
• Clarify session lifecycle: document that session_id should be stable per user/conversation, that state persists across calls, and recommend cleanup strategy (e.g., 'sessions auto-expire after 24h of inactivity').
• Add tool annotations in FastMCP: use @mcp.tool(readOnlyHint=True, idempotentHint=True) to declare that analyze_prompt is safe to retry and does not modify state.

Inferred effective spec: 2026-07-28+.

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