improvement(copilot): improve copilot metadata processing and tool output memory

[Sg312]

Summary

Adds metadata processing tools to copilot to limit bloated context

Type of Change

• Bug fix

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		Dec 22, 2025 6:55am

[greptile-apps]

Greptile Summary

This PR adds two new copilot tools (get_block_options and get_block_config) to improve how the AI assistant retrieves and processes block metadata. The get_block_options tool provides a list of available operations for a block type, while get_block_config returns detailed input/output schemas with operation-specific filtering.

Key improvements:

• Enhanced metadata extraction with operation-specific field filtering in get_block_config
• Smart handling of dynamic options (e.g., model lists) via store state mocking when server-side state is unavailable
• Improved tool output memory by storing full result objects in markToolComplete (third parameter), not just summary counts
• Comprehensive schema mapping covering 24+ subBlock types to simplified type strings
• Proper validation and error handling across client/server boundaries

Implementation details:

• Both tools follow the established client/server architecture pattern
• Server tools extract metadata from block registry and tool definitions
• Client tools fetch via API and store results for LLM context
• All changes properly registered in registry, router, and store instantiators

Confidence Score: 5/5

• This PR is safe to merge with no significant risks
• The implementation follows established patterns, has comprehensive error handling, proper schema validation with Zod, and stores full tool results for improved copilot memory. The code is well-structured with clear separation of concerns.
• No files require special attention

Important Files Changed

Filename	Overview
apps/sim/lib/copilot/registry.ts	Registered two new tools with proper schemas, SSE handlers, and result validators in the copilot registry
apps/sim/lib/copilot/tools/client/blocks/get-block-config.ts	Client-side implementation that fetches block configuration (inputs/outputs), storing full result data for copilot memory via markToolComplete
apps/sim/lib/copilot/tools/server/blocks/get-block-options.ts	Server-side tool that extracts available operations from block registry, handling both operation dropdown and tool access patterns
apps/sim/lib/copilot/tools/server/blocks/get-block-config.ts	Complex server-side tool that extracts block schemas with operation-specific filtering, dynamic options resolution with store mocking, and comprehensive input/output extraction

Sequence Diagram

sequenceDiagram
    participant Copilot as Copilot (LLM)
    participant Client as Client Tool
    participant API as API Route
    participant Server as Server Tool
    participant Registry as Block Registry
    participant Store as Zustand Store

    Note over Copilot,Store: get_block_options flow
    Copilot->>Client: Call get_block_options(blockId)
    Client->>Client: setState(executing)
    Client->>API: POST /api/copilot/execute-copilot-server-tool
    API->>Server: routeExecution('get_block_options', payload)
    Server->>Registry: blockRegistry[blockId]
    Registry-->>Server: blockConfig
    Server->>Server: Extract operations from subBlocks
    Server->>Server: Resolve tool descriptions
    Server-->>API: {blockId, blockName, operations[]}
    API-->>Client: Response with operations
    Client->>Client: markToolComplete(200, {operations: count}, result)
    Note over Client,Store: Result stored in memory for LLM context
    Client->>Client: setState(success)
    Client-->>Copilot: Operations list available

    Note over Copilot,Store: get_block_config flow
    Copilot->>Client: Call get_block_config(blockType, operation?)
    Client->>Client: setState(executing)
    Client->>API: POST /api/copilot/execute-copilot-server-tool
    API->>Server: routeExecution('get_block_config', payload)
    Server->>Registry: blockRegistry[blockType]
    Registry-->>Server: blockConfig
    Server->>Server: extractInputsFromSubBlocks(subBlocks, operation)
    Note over Server: Filters subBlocks by operation condition
    Server->>Server: resolveSubBlockOptions(sb)
    Note over Server: Calls dynamic options with mock store state
    Server->>Server: callOptionsWithFallback(optionsFn)
    Server->>Store: Mock useProvidersStore.getState()
    Store-->>Server: Static model options
    Server->>Server: extractOutputs(blockConfig, operation)
    Server-->>API: {blockType, inputs{}, outputs{}}
    API-->>Client: Response with config
    Client->>Client: markToolComplete(200, {inputs: count, outputs: count}, result)
    Note over Client,Store: Full schema stored for LLM reference
    Client->>Client: setState(success)
    Client-->>Copilot: Block configuration available

Loading

[greptile-apps]

Greptile's behavior is changing!

From now on, if a review finishes with no comments, we will not post an additional "statistics" comment to confirm that our review found nothing to comment on. However, you can confirm that we reviewed your changes in the status check section.

_{This feature can be toggled off in your Code Review Settings by deselecting "Create a status check for each PR".}