Polter exposes only 2 tools with minimal documentation. Both tools have descriptions (auth: 'Authenticate...', me: 'Query information...'), but descriptions are generic and lack actionable context for LLM selection. Input schemas are present but sparse: 'auth' accepts a single 'token' string parameter with a description; 'me' accepts no parameters. Neither tool documents output schemas, error conditions, or recovery guidance. No parameter constraints (enums, ranges, patterns) are visible. Tool names lack action verbs ('me' is particularly vague, does it return user info, session state, or terminal metadata?). No evidence of idempotency hints, permission gates, or audit logging. The server appears to be a terminal authentication/session gateway rather than a general-purpose tool suite, which limits its utility as an MCP server for agent composition.

• Rename 'me' to 'get_session_info' or 'describe_terminal' to convey the action and clarify what data is returned.
• Document output schemas for both tools. E.g., 'auth returns {success: bool, session_id: string, expires_at: ISO8601}' and 'me returns {terminal_id: string, user: string, session_status: string}'.
• Add parameter constraints to 'auth': 'token must be exactly 64 hexadecimal characters (32 bytes)'. Include validation error guidance.
• Add error handling descriptions: 'If token is invalid, returns error 'Invalid token format'. Retry with a valid 64-character hex token.' and 'If session expired, call auth() again with a fresh token.'
• Clarify whether 'token' is a secret that should be injected server-side or a user-provided credential. If user-provided, document the security implications and recommend server-side injection patterns.