feat(copilot): add context7

[Sg312]

Summary

Add context7 tool to copilot

Type of Change

• New feature

Testing

Manual

Checklist

• Code follows project style guidelines
• Self-reviewed my changes
• Tests added/updated and passing
• No new warnings introduced
• I confirm that I have read and agree to the terms outlined in the Contributor License Agreement (CLA)

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

1 Skipped Deployment

Project	Deployment	Review	Updated (UTC)
docs	Skipped		Jan 13, 2026 0:57am

[greptile-apps]

Greptile Overview

Greptile Summary

This PR adds a new copilot tool called search_library_docs that enables searching for library-specific documentation using external search APIs. The implementation follows established patterns in the codebase very closely, mirroring the structure of existing tools like search_online and search_documentation.

What Changed

New Files Created:

• Client-side tool implementation (SearchLibraryDocsClientTool) for UI state management and API communication
• Server-side tool implementation (searchLibraryDocsServerTool) for executing searches via Exa and Serper APIs

Modified Files:

• Server tool router updated to register the new tool
• Copilot store updated to register client tool instantiator and metadata

Implementation Details

The tool accepts three parameters:

• library_name (required): The name of the library to search documentation for
• query (required): The search query
• version (optional): Specific library version to target

The server implementation uses a dual-API strategy:

1. Primary: Attempts Exa API first (better for documentation searches)
2. Fallback: Falls back to Serper API if Exa is unavailable or fails
3. Error handling: Throws clear error if neither API key is configured

Search queries are automatically enhanced with "documentation" context and optional version information to target library-specific results.

Code Quality

✅ Follows existing patterns: Implementation is nearly identical to search_online and search_documentation tools
✅ Proper validation: Validates required parameters with appropriate type checks
✅ Error handling: Comprehensive try-catch blocks with detailed logging
✅ State management: Correct use of ClientToolCallState transitions
✅ Registration: Tool properly registered in both client and server registries

Minor Style Note

One small style improvement opportunity exists: the client tool has a redundant setState(success) call (lines 70 and 76), though this pattern exists in other similar tools throughout the codebase.

Confidence Score: 5/5

• This PR is safe to merge with minimal risk
• The implementation follows well-established patterns in the codebase, includes proper error handling and validation, and makes only additive changes without modifying existing functionality. The code quality is high with comprehensive logging and graceful fallback mechanisms.
• No files require special attention - all changes follow existing patterns and best practices

Important Files Changed

File Analysis

Filename	Score	Overview
apps/sim/lib/copilot/tools/client/other/search-library-docs.ts	5/5	New client tool implementation follows existing patterns correctly, with proper error handling and state management
apps/sim/lib/copilot/tools/server/docs/search-library-docs.ts	5/5	Server tool correctly implements dual API strategy (Exa + Serper fallback) with proper validation and error handling
apps/sim/lib/copilot/tools/server/router.ts	5/5	Tool registration added correctly to server tool registry
apps/sim/stores/panel/copilot/store.ts	5/5	Client tool properly registered in instantiator and metadata registries

Sequence Diagram

sequenceDiagram
    participant User
    participant Copilot
    participant ClientTool as SearchLibraryDocsClientTool
    participant API as /api/copilot/execute-copilot-server-tool
    participant Router as Server Tool Router
    participant ServerTool as searchLibraryDocsServerTool
    participant Exa as Exa API
    participant Serper as Serper API

    User->>Copilot: Request library documentation
    Copilot->>ClientTool: execute({ library_name, query, version? })
    ClientTool->>ClientTool: setState(executing)
    ClientTool->>API: POST with toolName & payload
    API->>Router: routeExecution('search_library_docs', params)
    Router->>ServerTool: execute(params)
    
    ServerTool->>ServerTool: Validate library_name & query
    ServerTool->>ServerTool: Build search query with library + version
    
    alt Has EXA_API_KEY
        ServerTool->>Exa: executeTool('exa_search', { query, numResults: 10 })
        alt Exa succeeds with results
            Exa-->>ServerTool: Return search results
            ServerTool-->>Router: Transform & return results
        else Exa fails or no results
            Exa-->>ServerTool: Error or empty results
            Note over ServerTool: Fall back to Serper
        end
    end
    
    alt No Exa key OR Exa failed
        alt Has SERPER_API_KEY
            ServerTool->>Serper: executeTool('serper_search', { query, num: 10 })
            Serper-->>ServerTool: Return search results
            ServerTool-->>Router: Transform & return results
        else No Serper key
            ServerTool-->>Router: Error: No API keys available
        end
    end
    
    Router-->>API: Return results
    API-->>ClientTool: HTTP 200 with results
    ClientTool->>ClientTool: setState(success)
    ClientTool->>ClientTool: markToolComplete(200, message, data)
    ClientTool-->>Copilot: Tool complete
    Copilot-->>User: Display library documentation results

Loading

[greptile-apps]

_{1 file reviewed, 1 comment}

_{Edit Code Review Agent Settings | Greptile}

[greptile-apps]

The state is set to ClientToolCallState.success twice (lines 70 and 76). While this follows the existing pattern in other similar tools like SearchOnlineClientTool and SearchDocumentationClientTool, this redundancy could be removed for cleaner code.

Suggested change

	this.setState(ClientToolCallState.success)
	await this.markToolComplete(
	200,
	`Library documentation search complete for ${args?.library_name || 'unknown'}`,
	parsed.result
	)
	this.setState(ClientToolCallState.success)
	const json = await res.json()
	const parsed = ExecuteResponseSuccessSchema.parse(json)
	await this.markToolComplete(
	200,
	`Library documentation search complete for ${args?.library_name || 'unknown'}`,
	parsed.result
	)
	this.setState(ClientToolCallState.success)

_{Note: If this suggestion doesn't match your team's coding style, reply to this and let me know. I'll remember it for next time!}

Prompt To Fix With AI

This is a comment left during a code review.
Path: apps/sim/lib/copilot/tools/client/other/search-library-docs.ts
Line: 70:76

Comment:
The state is set to `ClientToolCallState.success` twice (lines 70 and 76). While this follows the existing pattern in other similar tools like `SearchOnlineClientTool` and `SearchDocumentationClientTool`, this redundancy could be removed for cleaner code.

```suggestion
      const json = await res.json()
      const parsed = ExecuteResponseSuccessSchema.parse(json)
      await this.markToolComplete(
        200,
        `Library documentation search complete for ${args?.library_name || 'unknown'}`,
        parsed.result
      )
      this.setState(ClientToolCallState.success)
```

<sub>Note: If this suggestion doesn't match your team's coding style, reply to this and let me know. I'll remember it for next time!</sub>

How can I resolve this? If you propose a fix, please make it concise.