Skip to main content
Glama

close_browser

Close the browser instance to release system resources while preserving LinkedIn credentials for future sessions.

Instructions

Close the browser instance and release resources. Credentials are preserved.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

Implementation Reference

  • MCP tool registration with @mcp.tool decorator. Registers 'close_browser' with description and defines the handler that wraps the use case, returning a dict with is_valid and message fields.
    @mcp.tool(
        name="close_browser",
        description="Close the browser instance and release resources. Credentials are preserved.",
    )
    async def close_browser(ctx: Context) -> dict[str, Any]:
        try:
            result = await manage_session_uc.close_browser()
            return {
                "is_valid": result.is_valid,
                "message": result.message,
            }
        except Exception as e:
            map_domain_error(e, "close_browser")
  • Core business logic implementation. Closes the browser instance via the BrowserPort and returns a SessionStatus indicating the browser is closed.
    async def close_browser(self) -> SessionStatus:
        """Close the browser instance and release resources."""
        await self._browser.close()
        return SessionStatus(is_valid=False, message="Browser closed")
  • SessionStatus dataclass schema. Defines the structure returned by the close_browser use case with is_valid (bool), profile_path (optional str), and message (str) fields.
    @dataclass
    class SessionStatus:
        """Represents the status of a browser session."""
    
        is_valid: bool
        profile_path: str | None = None
        message: str = ""
  • MCP tool handler function. Receives Context, calls manage_session_uc.close_browser(), and transforms the SessionStatus result into a dict response with error handling.
    async def close_browser(ctx: Context) -> dict[str, Any]:
        try:
            result = await manage_session_uc.close_browser()
            return {
                "is_valid": result.is_valid,
                "message": result.message,
            }
  • Registration call site. Invokes register_session_tools to register the close_browser tool with the MCP server instance.
    register_session_tools(mcp, container.manage_session)
Behavior4/5

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

With no annotations provided, the description carries full burden and does well by disclosing key behavioral traits: it destroys the browser instance, releases resources, and preserves credentials. It doesn't mention error conditions or side effects, but covers the essential mutation behavior adequately.

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?

Two concise sentences with zero waste. The first sentence states the core action and consequence, the second adds crucial credential preservation detail. Every word earns its place in this well-structured description.

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

Completeness5/5

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

Given the tool's simple nature (no parameters, has output schema), the description provides complete context for understanding what the tool does and its behavioral implications. It covers the mutation aspect, resource management, and credential handling without needing to explain return values.

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?

With 0 parameters and 100% schema description coverage, the baseline is 4. The description appropriately doesn't discuss parameters since none exist, focusing instead on the tool's behavioral impact.

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

Purpose5/5

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

The description clearly states the specific action ('Close the browser instance') and the resource affected ('browser instance'), distinguishing it from all sibling tools which are data retrieval operations. It adds meaningful context about resource release, making the purpose unambiguous.

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 implies usage context by mentioning resource release and credential preservation, suggesting this should be used when cleaning up browser sessions. However, it doesn't explicitly state when to use this tool versus alternatives or provide exclusion criteria, leaving some guidance gaps.

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/eliasbiondo/linkedin-mcp-server'

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