Skip to main content
Glama
hmumixaM

USCardForum MCP Server

by hmumixaM

get_current_session

Retrieve current user session details including authentication status and user information from the USCardForum MCP Server.

Instructions

Get information about the current session.

Returns a Session object with:
- is_authenticated: Whether logged in
- current_user: CurrentUser object with user info (if authenticated)

Use to verify authentication status.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
current_userNoLogged-in user
is_authenticatedNoWhether authenticated

Implementation Reference

  • The MCP tool handler implementation for 'get_current_session'. It is decorated with @mcp.tool() and delegates to the shared client's get_current_session method to retrieve the current authentication session.
    @mcp.tool()
    def get_current_session() -> Session:
        """
        Get information about the current session.
    
        Returns a Session object with:
        - is_authenticated: Whether logged in
        - current_user: CurrentUser object with user info (if authenticated)
    
        Use to verify authentication status.
        """
        return get_client().get_current_session()
  • Pydantic BaseModel defining the output schema for the get_current_session tool. Includes fields for current_user (optional) and is_authenticated boolean, with a classmethod for parsing from API responses.
    class Session(BaseModel):
        """Current session information."""
    
        current_user: CurrentUser | None = Field(None, description="Logged-in user")
        is_authenticated: bool = Field(False, description="Whether authenticated")
    
        class Config:
            extra = "ignore"
    
        @classmethod
        def from_api_response(cls, data: dict[str, Any]) -> "Session":
            """Parse from raw API response."""
            user_data = data.get("current_user") or data.get("user")
            current_user = CurrentUser(**user_data) if user_data else None
            return cls(
                current_user=current_user,
                is_authenticated=current_user is not None,
            )
  • Helper method in DiscourseClient that implements the core session retrieval logic by delegating to the AuthAPI submodule.
    def get_current_session(self) -> Session:
        """Get current session info.
    
        Returns:
            Session data including user info
        """
        return self._auth.get_current_session()
  • Re-export of the get_current_session tool from the auth module, making it available at the server_tools package level for the MCP server entrypoint.
    from .auth import (
        login,
        get_current_session,
        get_notifications,
        bookmark_post,
        subscribe_topic,
    )
  • Import of get_current_session into the MCP server entrypoint module, where it is exposed in __all__ for automatic tool registration in main().
    from uscardforum.server_tools import (
        analyze_user,
        bookmark_post,
        compare_cards,
        find_data_points,
        get_all_topic_posts,
        get_categories,
        get_current_session,
        get_hot_topics,
        get_new_topics,
        get_notifications,
Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries the full burden. It discloses that the tool returns session information and authentication status, which is useful behavioral context. However, it doesn't mention potential errors, rate limits, or other operational traits beyond the basic return structure.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is front-loaded with the core purpose, followed by details on the return object and usage guidance. Every sentence adds value without redundancy, making it efficiently structured and appropriately sized for the tool's simplicity.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's low complexity (0 parameters, output schema exists), the description is mostly complete. It explains what the tool does and what it returns, but lacks details on error handling or edge cases, which holds it back from a perfect score.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The tool has 0 parameters, and schema description coverage is 100%. The description doesn't need to add parameter semantics, so it meets the baseline of 4 for zero-parameter tools, as it appropriately focuses on output and usage.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's purpose ('Get information about the current session') with a specific verb and resource. It distinguishes itself from siblings by focusing on session/authentication status rather than user data, topics, or posts, though it doesn't explicitly name alternatives.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides clear context for usage ('Use to verify authentication status'), which implicitly guides when to use it. However, it doesn't explicitly state when not to use it or name specific alternatives among the sibling tools.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/hmumixaM/uscardforum-mcp4'

If you have feedback or need assistance with the MCP directory API, please join our Discord server