Static source inference · medium confidence · detected: Sampling
Deprecated protocol patterns detected
Summary
This server exhibits significant gaps across naming, descriptions, schemas, and error handling. While tool names use action verbs (navigate, act, extract, observe, screenshot, get_url, agent, create_session, list_sessions, set_active_session, close_session), many descriptions are extremely brief (under 50 characters), parameter descriptions are sparse or missing entirely, input schemas are not fully visible in the provided source code, and output schemas are not documented. The extract tool has NO visible description at all. The act tool's description is unclear about what 'action' format to use, does it accept natural language or a structured format? The agent tool description promises 'autonomously navigate and interact' but offers no error guidance if the sub-agent fails. Parameters like 'action' in act and 'prompt' in agent lack constraint descriptions (format, length, examples). Error handling is not evident, there is no indication how tools handle network failures, invalid input, or timeout scenarios. Session management tools (create, list, set, close) lack clear descriptions of side effects and idempotency. The codebase shows tool.ts defines a ToolSchema type but actual instantiations are not provided in the excerpt, making it impossible to verify that ALL parameters have type definitions and descriptions.
Input schemas not visible in source code. Tool definitions reference schema: ToolSchema<Input> but actual parameter schemas (types, enums, constraints) are not provided in the excerpt. Cannot verify parameter type definitions and descriptions exist.
act tool's 'action' parameter description lacks constraint information. What format should 'action' be? Natural language? Structured template? Max length? Required format is ambiguous.
browserbase_stagehand_act
Recommendations
Add a complete, non-empty description to browserbase_stagehand_extract. Example: 'Extract structured information from the current page using natural language queries. Specify what data to extract (e.g., "all product names and prices") and receive results in a structured format.'
Provide full input schemas for all 7 tools missing visible schemas. Each tool must define: parameter names, types (string, object, number, boolean, enum), required vs optional, and per-parameter descriptions with format/constraint details.
Expand act tool description to clarify the action format. Example: 'Perform a single atomic action on the page. Describe the action in natural language (e.g., "Click the sign-in button" or "Type [password_var] into the password field"). Use variables for sensitive data to avoid logging credentials. One action per call.'
Expand agent tool description to document constraints and error handling. Example: 'Execute a task autonomously using a sub-agent. Provide a clear, specific prompt (50 - 500 characters). The sub-agent will navigate and interact to complete the task. Returns success/failure with summary. If the sub-agent fails, try breaking the task into smaller steps via multiple calls.'
Document the return schema for ALL tools. For example: observe should return {"html": string, "metadata": {...}}; list_sessions should return {"sessions": [{"id": string, "created_at": ISO8601, ...}], "total": number}; agent should return {"success": boolean, "result": string, "steps_taken": number}.
agent tool's 'prompt' parameter lacks constraints. No description of max length, required detail level, or expected scope. An LLM cannot assess whether a prompt is valid without this guidance.
No error handling guidance visible. Tools do not document what errors are possible, how to recover, or whether errors are retryable. Per pattern:recovery-guide, error responses must tell the LLM what to do next.
Output schemas not documented. No indication what fields tools return, whether results are paginated, or what data structure to expect. Per pattern:tool, LLMs must know what fields to expect so they can plan downstream calls.
Session management tools lack idempotency documentation. create_session, set_active_session, close_session do not describe side effects. Per pattern:idempotent-operation, agents retry on failure, LLMs need to know whether repeated calls are safe.
Descriptions are too short. Most tool descriptions are 20 - 50 characters (e.g., 'Navigate to a URL', 'Get the current URL'). Expanded descriptions should include prerequisites, common use cases, and when to prefer one tool over similar ones.
act tool's 'variables' parameter lacks clarity. Description says 'use variables if dealing with sensitive data', but this is vague. When exactly should variables be used? Why? What counts as 'sensitive'? Are variables required for text input or optional?
No pagination or result-limiting guidance. Tools like extract, observe, list_sessions offer no indication of max result size, pagination support, or how many items LLM should expect. Per mxe:enforce-result-limits, large unbounded results exhaust context.
Add error recovery guidance to each tool description. Example for agent: 'If the sub-agent fails with a network error, retry with the same prompt. If it fails with a task error, try a simpler version of the task.'
Clarify idempotency of session tools. Example for create_session: 'Creates a new session. Each call returns a unique session ID. Calling with identical parameters multiple times creates multiple sessions (not idempotent). Use set_active_session to switch between existing sessions.'
Document pagination for list_sessions. Example: 'Returns all active sessions. If many sessions exist, add pagination support: accept optional limit (default 20, max 100) and offset (default 0) parameters; return total session count.'
For act tool, clarify when and why to use variables. Example: 'Passwords, API keys, and PII should be passed via variables, not embedded in the action description. This prevents credentials from being logged. Example: {"action": "Enter password in login form", "variables": {"password": "..."}}.'
Add constraints to act tool's action parameter description. Example: 'Single, atomic action (max 200 characters). Use imperative voice ("Click", "Type", "Scroll"). Include target element context if ambiguous.'
Document timeout and network failure behavior for all tools. Example: 'If the page does not load within 30 seconds, returns a timeout error with the last observed state. Timeout errors are retryable.'
Add confirmation or dry-run support for destructive operations. close_session modifies state irreversibly, consider adding a 'force' parameter (default false) that requires explicit confirmation before closing, preventing accidental session termination.