Optional API Key Enforcement for MCP Servers

We’ve introduced a new project-level security setting that allows you to require API key authentication for all MCP server requests. This opt-in feature gives you fine-grained control over who can access your MCP endpoints.

What’s New

A new “Require API Key for MCP” toggle is now available in your Project Settings. When enabled, all requests to your MCP servers must include a valid Composio API key in the request headers.

How It Works

When the setting is disabled (default):

• MCP servers work without API key authentication
• Existing integrations continue to function unchanged

When the setting is enabled:

• All MCP requests must include the x-api-key header with a valid Composio API key
• Requests without a valid API key receive 401 Unauthorized
• Only API keys belonging to the same project are accepted

Request Examples

Without API key (when enforcement is enabled):

$
curl -X POST "https://mcp.composio.dev/{your_mcp_server_url}" \
>
  -H "Content-Type: application/json" \
>
  -d '{"jsonrpc":"2.0","id":1,"method":"initialize"}'
>
>
# Response: 401 Unauthorized

With API key:

$
curl -X POST "https://mcp.composio.dev/{your_mcp_server_url}" \
>
  -H "Content-Type: application/json" \
>
  -H "x-api-key: ak_your_api_key" \
>
  -d '{"jsonrpc":"2.0","id":1,"method":"initialize"}'
>
>
# Response: 200 OK

Enabling the Setting

Via Dashboard

1. Navigate to Project Settings
2. Go to the Project Configuration tab
3. Find the “Require API Key for MCP” toggle
4. Enable the toggle

Via API

Update your project configuration using the API:

$
curl -X PATCH "https://backend.composio.dev/api/v3/org/project/config" \
>
  -H "Content-Type: application/json" \
>
  -H "x-api-key: ak_your_api_key" \
>
  -d '{"require_mcp_api_key": true}'

Response:

1
{
2
  "require_mcp_api_key": true,
3
  "is_2FA_enabled": true,
4
  "mask_secret_keys_in_connected_account": true,
5
  "log_visibility_setting": "show_all"
6
}

Via Code

1
import requests
2
3
response = requests.patch(
4
    "https://backend.composio.dev/api/v3/org/project/config",
5
    headers={
6
        "Content-Type": "application/json",
7
        "x-api-key": "ak_your_api_key"
8
    },
9
    json={"require_mcp_api_key": True}
10
)
11
12
print(response.json())

When to Use This

Enable API key enforcement when you need to:

• Prevent unauthorized access to your MCP servers
• Control which applications can interact with your MCP endpoints
• Add an extra security layer for production deployments
• Audit and track MCP server usage through API key attribution

API Reference

Get Current Setting

1
GET /api/v3/org/project/config

Update Setting

1
PATCH /api/v3/org/project/config

1
{
2
  "require_mcp_api_key": true
3
}

Consistent Error Response Structure

Tool execution errors now return a standardized response format across all failure types. Previously, the data field was empty on errors—now it always includes status_code and message, matching the structure of successful responses.

What Changed

All error responses from tool execution now include:

• data.status_code: HTTP status code (or null for non-HTTP errors)
• data.message: Detailed error message
• error: Same detailed message at the top level

Before vs After

Previous error response:

1
{
2
  "data": {},
3
  "successfull": false,
4
  "error": "404 Client Error: Not Found for url: ...",
5
}

New error response:

1
{
2
  "data": {
3
      "http_error": "404 Client Error: Not Found for url: ...",
4
      "status_code": 404,
5
      "message": "Resource not found: The requested item does not exist"
6
  },
7
  "successfull": false,
8
  "error": "Resource not found: The requested item does not exist",
9
}

Why This Matters

• Easier parsing: Agents and code can reliably access error details from data.message without special-casing empty data objects
• Better debugging: Detailed error messages replace generic HTTP error strings
• Consistent schema: Same response shape whether the tool succeeds or fails

Union Types Preserved in Tool Schemas

Tool schemas now use standard JSON Schema anyOf for union types, providing accurate type information for LLMs and code generators.

What Changed

Two changes affect how types appear in request/response schemas:

Before vs After

For example, the GOOGLECALENDAR_GET_CURRENT_DATE_TIME request schema changes: Previous (only a single type):

1
{
2
  "timezone": {
3
    "default": 0,
4
    "description": "Timezone specification...",
5
    "title": "Timezone",
6
    "type": "string"
7
  }
8
}

Now (Union types preserved):

1
{
2
  "timezone": {
3
    "anyOf": [
4
      { "type": "string" },
5
      { "type": "number" }
6
    ],
7
    "default": 0,
8
    "description": "Timezone specification...",
9
    "title": "Timezone"
10
  }
11
}

Similarly, nullable fields like page_token in GOOGLECALENDAR_LIST_CALENDARS:

Previous:

1
{
2
  "page_token": {
3
    "default": null,
4
    "description": "Token for the page of results to return...",
5
    "nullable": true,
6
    "title": "Page Token",
7
    "type": "string"
8
  }
9
}

Now:

1
{
2
  "page_token": {
3
    "anyOf": [
4
      { "type": "string" },
5
      { "type": "null" }
6
    ],
7
    "default": null,
8
    "description": "Token for the page of results to return...",
9
    "title": "Page Token"
10
  }
11
}

Why This Matters

• Accurate schemas: LLMs and code generators see the full set of allowed types
• Better validation: Input validation can now correctly accept all valid types, not just the first one

Deprecating BEARER_TOKEN auth scheme for 19 toolkits

We’ve deprecated the BEARER_TOKEN auth scheme for the following 19 toolkits:

• Airtable
• Discord
• Discordbot
• Gmail
• Google Classroom
• Google Search Console
• Google Calendar
• Google Docs
• Google Drive
• Google Slides
• Google Super
• Instagram
• Ntfy
• Sapling AI
• Slack
• Slackbot
• Tawk To
• TikTok
• Twitter

Recommendation

For these toolkits, we recommend using alternative auth schemes (for example, OAUTH2, API_KEY, or other toolkit-supported schemes) instead of BEARER_TOKEN.

Backward compatibility (explicit)

This change is fully backward compatible:

• Existing auth configs and connected accounts created with BEARER_TOKEN will continue to function.
• Creating new auth configs and connected accounts with BEARER_TOKEN will continue to work (e.g., via API/SDK).
• To discourage new usage, BEARER_TOKEN auth configs / connected accounts will not be displayed in the UI for these toolkits.

Binary Data Support for Proxy Execute

The /api/v3/tools/execute/proxy endpoint now supports binary data for both file uploads and downloads.

File Uploads (binary_body)

To upload a file via the proxy, use the binary_body field in your request payload. This supports two approaches: specifying either a URL pointing to the file or providing the base64-encoded content directly.

Upload File via URL

$
curl --location 'https://backend.composio.dev/api/v3/tools/execute/proxy' \
>
  --header 'accept: application/json' \
>
  --header 'x-api-key: <YOUR_API_KEY>' \
>
  --header 'Content-Type: application/json' \
>
  --data '{
>
    "endpoint": "/upload-endpoint",
>
    "method": "POST",
>
    "connected_account_id": "<CONNECTED_ACCOUNT_ID>",
>
    "binary_body": {
>
      "url": "{URL_TO_THE_FILE}"
>
    }
>
  }'

Upload File via Base64 Content

Supported up to 4MB file size.

$
curl --location 'https://backend.composio.dev/api/v3/tools/execute/proxy' \
>
  --header 'accept: application/json' \
>
  --header 'x-api-key: <YOUR_API_KEY>' \
>
  --header 'Content-Type: application/json' \
>
  --data '{
>
    "endpoint": "/upload-endpoint",
>
    "method": "POST",
>
    "connected_account_id": "<CONNECTED_ACCOUNT_ID>",
>
    "binary_body": {
>
      "base64": "JVBERi0xLjQKJ...<base64_data>...",
>
      "content_type": "application/pdf"
>
    }
>
  }'

File Downloads (binary_data)

When the proxied request returns a binary response (for example, a PDF or image), the proxy automatically uploads the file to temporary storage, and you receive a signed URL in the binary_data field. This enables you to download large files securely.

File Download Request

$
curl --location 'https://backend.composio.dev/api/v3/tools/execute/proxy' \
>
  --header 'accept: application/json' \
>
  --header 'x-api-key: <YOUR_API_KEY>' \
>
  --header 'Content-Type: application/json' \
>
  --data '{
>
    "endpoint": "{YOUR_ENDPOINT}",
>
    "method": "GET",
>
    "connected_account_id": "{YOUR_CONNECTED_ACCOUNT_ID}"
>
  }'

File Download Response

1
{
2
  "data": {},
3
  "binary_data": {
4
    "url": "url to the file",
5
    "content_type": "content type of the file",
6
    "size": "size of the file",
7
    "expires_at": "expires at of the file"
8
  },
9
  "status": "status code of the response",
10
  "headers": "headers of the response"
11
}

Summary

We’d love your feedback on the new proxy execute capabilities. If anything feels unclear or you have suggestions for improvement, please reach out.

Lookahead Announcement

We’re introducing Webhook Payload V3 - a redesigned webhook structure that follows industry standards and provides better developer experience. This update affects how you receive trigger events via webhooks and Pusher.

What’s Changing?

New Webhook Structure

We’re adopting the Standard Webhooks specification for better consistency and reliability.

Headers

A new header will identify the webhook version:

x-composio-webhook-version: V3

Payload Structure

The payload structure is being reorganized to separate Composio metadata from trigger data:

Before (V2):

1
{
2
  "log_id": "log_TpxVOLXYnwXZ",
3
  "timestamp": "2025-12-23T13:06:07.695Z",
4
  "type": "gmail_new_gmail_message",
5
  "data": {
6
    "connection_id": "a1b2c3d4-5e6f-7a8b-9c0d-1e2f3a4b5c6d",
7
    "connection_nano_id": "ca_xYz9AbCdEfGh",
8
    "trigger_nano_id": "ti_JZFoTyYKbzhB",
9
    "trigger_id": "7f8e9d0c-1b2a-3c4d-5e6f-7a8b9c0d1e2f",
10
    "user_id": "usr-demo-12a3b4c5...",
11
    // ... actual trigger data mixed with metadata
12
  }
13
}

After (V3):

1
{
2
  "id": "msg_a1b2c3d4-5e6f-7a8b-9c0d-1e2f3a4b5c6d",
3
  "timestamp": "2025-12-23T13:06:07.695Z",
4
  "type": "composio.trigger.message",
5
  "metadata": {
6
    "log_id": "log_TpxVOLXYnwXZ",
7
    "trigger_slug": "GMAIL_NEW_GMAIL_MESSAGE",
8
    "auth_config_id": "ac_aCYTppZ5RsRc",
9
    "connected_account_id": "ca_cATYssZ5RrSc",
10
    "trigger_id": "ti_JZFoTyYKbzhB",
11
    "user_id": "pg-test-86c9fc84..."
12
  },
13
  "data": {
14
    // Clean trigger data without Composio metadata
15
  }
16
}

Key Improvements

1. Metadata Separation: Composio-specific fields (connection IDs, trigger IDs, user IDs) are now in a dedicated metadata object
2. Clean Data: The data field now contains only the actual trigger payload without infrastructure metadata
3. Standardized Type Field: The type field now follows a consistent format (composio.trigger.message) instead of trigger-specific names like gmail_new_gmail_message
4. Trigger Slug in Metadata: The trigger slug (e.g., GMAIL_NEW_GMAIL_MESSAGE) is now available in metadata.trigger_slug for easy identification
5. Standards Compliance: Follows Standard Webhooks specification for better interoperability
6. Consistent Structure: Same payload structure for both webhooks and Pusher channels

Migration Guide

Updating Your Webhook Handlers

If you’re accessing Composio metadata fields, update your code:

1
# Before (V2)
2
trigger_type = payload["type"]  # "gmail_new_gmail_message"
3
connection_id = payload["data"]["connection_id"]
4
trigger_id = payload["data"]["trigger_id"]
5
message_text = payload["data"]["message_text"]
6
7
# After (V3)
8
trigger_type = payload["type"]  # "composio.trigger.message"
9
trigger_slug = payload["metadata"]["trigger_slug"]  # "GMAIL_NEW_GMAIL_MESSAGE"
10
connection_id = payload["metadata"]["connected_account_id"]
11
trigger_id = payload["metadata"]["trigger_id"]
12
message_text = payload["data"]["message_text"]

1
// Before (V2)
2
const triggerSlug = payload.type;  // "gmail_new_gmail_message"
3
const connectionId = payload.data.connection_id;
4
const triggerId = payload.data.trigger_id;
5
const messageText = payload.data.message_text;
6
7
// After (V3)
8
const webhookType = payload.type;  // "composio.trigger.message"
9
const triggerSlug = payload.metadata.trigger_slug;  // "GMAIL_NEW_GMAIL_MESSAGE"
10
const connectionId = payload.metadata.connected_account_id;
11
const triggerId = payload.metadata.trigger_id;
12
const messageText = payload.data.message_text;

Checking Webhook Version

You can detect the webhook version from headers:

1
webhook_version = headers.get("x-composio-webhook-version", "V2")
2
if webhook_version == "V3":
3
    # Use new structure
4
    metadata = payload["metadata"]
5
else:
6
    # Use old structure
7
    metadata = payload["data"]

Rollout Timeline

• December 2025: V3 released, opt-in via project settings
• February 15, 2026: All new organizations will default to V3
• Existing organizations: Continue using V2 by default, can opt-in to V3 anytime

How to Opt-In

1. Go to your project settings in the Composio dashboard
2. Navigate to the Webhooks section
3. Select “Webhook Payload Version: V3”
4. Update your webhook handlers to use the new structure
5. Test thoroughly before enabling in production

Benefits

• Better DX: Clear separation between metadata and actual trigger data
• Standards Compliance: Follows industry-standard webhook specifications
• Consistency: Same structure across webhooks and Pusher channels
• Future-Proof: Built on established standards for long-term compatibility

Need Help?

If you have questions about migrating to V3 or need assistance:

• Join our Discord community
• Check our documentation
• Contact support at support@composio.dev

Authentication & Configuration Updates Across Multiple Toolkits

Summary

This release includes significant authentication and configuration improvements across 16+ toolkits. The changes standardize Base URL handling, modernize authentication methods, and fix various endpoint configurations to improve reliability and flexibility.

Breaking Changes

We verified that active usage for these toolkits is practically zero before proceeding with these changes.

Make Toolkit

• Removed Region field in favor of explicit Base URL configuration
• Users must now provide the full Base URL instead of selecting a region
• This change provides more flexibility for custom deployments and regional endpoints

Bubble Toolkit

• Removed Subdomain field and restructured Base URL handling
• Users must now provide the complete Base URL instead of just the Subdomain
• This change standardizes URL configuration across all toolkits

Deprecated Features

HelloBar Toolkit

• Bearer authentication is now deprecated
• While still functional, users are encouraged to migrate to newer authentication methods
• Support for bearer tokens will be removed in a future release

FormSite Toolkit

• Bearer authentication deprecated in favor of API key authentication
• New integrations should use API key authentication for improved security
• Existing bearer token implementations will continue to work but should be migrated

Improvements & Fixes

Configuration Improvements

Linear Toolkit

• Base URL is no longer a configurable field
• The toolkit now uses a fixed endpoint, simplifying the authentication process

Kibana Toolkit

• Removed the default value for Base URL, allowing for more flexible deployment configurations
• Users can now specify custom Kibana instances without overriding defaults

Gong Toolkit

• Added a sensible default value for Base URL to simplify initial setup
• New users can connect without manually configuring the endpoint

Insightly Toolkit

• Added default value for the Pod field to streamline configuration
• Reduces setup complexity for standard deployments

ClickUp Toolkit

• Fixed the Base URL field type for proper validation and handling
• Ensures consistent URL formatting across all operations

Dynamic Endpoint Updates

Brilliant Directories Toolkit

• Implemented dynamic Base URL resolution for the Get Current User Endpoint
• Automatically adapts to different deployment environments

Braintree Toolkit

• Updated configuration to use production defaults
• Implemented dynamic endpoint resolution for better environment handling
• Improved reliability for production deployments

Auth0 Toolkit

• Replaced hardcoded endpoints with dynamic tenant-based URL resolution
• Supports multi-tenant deployments without manual configuration
• Automatically constructs the correct endpoint based on the tenant configuration

Endpoint Fixes

DataScope Toolkit

• Fixed the Get Current User Endpoint to use the correct API path
• Resolves authentication verification issues

D2L Brightspace Toolkit

• Updated the Get Current User Endpoint to match the latest API specifications
• Ensures proper user identification and session validation

Migration Guide

For toolkits with breaking changes, please update your configurations as follows:

1. Make: Replace Region with the full Base URL (e.g., https://us-east-1.make.com)
2. Bubble: Replace Subdomain with the full Base URL (e.g., https://myapp.bubbleapps.io)

For deprecated authentication methods:

• HelloBar & FormSite: Generate new API keys from your account settings and update your authentication configuration

Authentication Updates Across Multiple Toolkits

We’ve updated authentication configurations for several toolkits to improve security, fix issues, and support additional deployment options.

Summary

Breaking Changes

These toolkits had incorrect or outdated authentication configurations that needed fixing. We verified that active usage for these toolkits is practically zero before proceeding with these changes.

Impact: Existing connections will stop working. You’ll need to create new auth configs and ask affected users to reconnect.

Make

Replaced region-based configuration with full base URL input. Users now provide the complete Make instance URL (e.g., https://us2.make.com or https://us1.make.celonis.com) instead of just a region code.

Recall AI

Updated from region-based to full base URL configuration. Fixed field descriptions and metadata. Updated categories to AI/Productivity/Communication and added proper documentation links.

Relevance AI

Simplified authentication by removing deprecated Project ID field. Added conditional mapping for region codes to API subdomains (AU→f1db6c, EU→d7b62b, US→bcbe5a). Region field now defaults to US.

SmartRecruiters

Fixed OAuth configuration with correct SmartRecruiters endpoints. Added proper default scopes for candidates, jobs, and users. Enabled PKCE and added refresh token support.

Deprecated (Still Working)

These changes introduce new auth methods while keeping old ones functional:

Ashby

Added new API Key authentication scheme with automatic base64 encoding and proper authorization headers.

No Action Required: Old Basic Auth method is deprecated but continues to work. Existing connections are unaffected.

Freshdesk

Added new API Key authentication scheme requiring subdomain and API key with automatic base64 encoding.

No Action Required: Old Basic Auth method is deprecated but continues to work. Existing connections are unaffected.

Freshservice

Added new API Key authentication scheme requiring subdomain and API key with automatic base64 encoding.

No Action Required: Old Basic Auth method is deprecated but continues to work. Existing connections are unaffected.

Trello

Marked Bearer Token authentication as deprecated in favor of OAuth authentication.

No Action Required: Old Bearer auth continues to function. OAuth is recommended for new connections.

ZoomInfo

Added new OAuth2 authentication scheme with comprehensive scopes for contacts, companies, audiences, scoops, news, and intent data. Deprecated the old JWT-based Basic authentication. Password field now properly marked as secret.

No Action Required: Old JWT auth continues to function. New connections will use OAuth2.

Non-Breaking Improvements

Mixpanel

Fixed region mapping logic for data residency. Added proper conditional evaluation to map regions to correct API hosts (EU, India, or Standard). Region field is now optional and defaults to Standard server. Service account secret now properly marked as secret.

No Action Required: Existing connections continue to work without changes.

Supabase

Changed base_url field type from auth_config_field to connection_field for both OAuth and API Key schemes. Updated base action logic to respect user-provided base URLs, enabling support for self-hosted Supabase instances.

No Action Required: Existing connections continue to work. Self-hosted instances now supported.

Toolkit Deprecation: Removing Empty Toolkits

What’s Changed

We’re deprecating 15 toolkits that currently have no supported actions. These toolkits will be reactivated once we add functional actions to them, ensuring you only see integrations that are ready to use.

Deprecated Toolkits

The following toolkits are now deprecated:

• BREATHEHR, DIXA, EGNYTE, EXPENSIFY, FREEAGENT
• GUSTO, NUTSHELL, OPENNUTRITION, OYSTERHR, RAKUTEN
• SALESFLARE, TEAMLEADER, WALGREENS, WHOOP, WIX

Impact on Your Integration

API Behavior Changes

List Toolkits Endpoint

The GET /toolkits endpoint will now exclude deprecated toolkits by default.

Need to see deprecated toolkits? Use the include_deprecated query parameter.

Backward Compatibility

Your existing integrations are safe. All other endpoints continue to work with deprecated toolkits:

• Retrieve the toolkit details
• Create auth configurations
• Manage connected accounts
• Configure MCP Servers

This ensures zero breaking changes to your current implementations.

Why This Matters

This change helps you:

• Focus on working integrations - No clutter from non-functional toolkits
• Avoid integration attempts with toolkits that have no actions
• Better developer experience with a cleaner, more actionable toolkit list

Questions?

If you have questions or need support with any deprecated toolkit, reach out to our team or check our documentation.

Toolkit Deprecation: Streamlining Our Platform

What’s Changed

We’re deprecating 60 toolkits that currently have no supported actions. These toolkits will be reactivated once we add functional actions to them, ensuring you only see integrations that are ready to use.

Deprecated Toolkits

The following toolkits are now deprecated:

• ACCELO, ADOBE, AERO_WORKFLOW, AMAZON, APEX27
• APPOINTO, APPSFLYER, ATLASSIAN, AUTH0, AXONAUT
• BATTLENET, BOLDSIGN, BRAINTREE, BREEZY_HR, BREX_STAGING
• BRIGHTPEARL, BROWSERHUB, CUSTOMER_IO, DEEL, DRIP_JOBS
• EPIC_GAMES, FACTORIAL, FITBIT, FRONT, GO_TO_WEBINAR
• GURU, HELCIM, HIGHLEVEL, ICIMS_TALENT_CLOUD, IDEA_SCALE
• KEAP, LASTPASS, LEVER_SANDBOX, LEXOFFICE, MANY_CHAT
• MBOUM, MICROSOFT_TENANT, MOXIE, ONCEHUB, POPTIN
• PRECORO, PRINTNODE, QUALAROO, RAVENSEOTOOLS, RING_CENTRAL
• RIPPLING, SAGE, SALESFORCE_MARKETING_CLOUD, SEISMIC, SMARTRECRUITERS
• TAPFORM, TERMINUS, TIMEKIT, TWITCH, VENLY
• VERO, VISME, WAVE_ACCOUNTING, WIZ, ZOHO_DESK

Impact on Your Integration

API Behavior Changes

List Toolkits Endpoint

The GET /toolkits endpoint will now exclude deprecated toolkits by default.

Need to see deprecated toolkits? Use the new include_deprecated query parameter.

Backward Compatibility

Your existing integrations are safe. All other endpoints continue to work with deprecated toolkits:

• ✅ Retrieve the toolkit details
• ✅ Create auth configurations
• ✅ Manage connected accounts
• ✅ Configure MCP Servers

This ensures zero breaking changes to your current implementations.

Why This Matters

This change helps you:

• Focus on working integrations - No clutter from non-functional toolkits
• Avoid integration attempts with toolkits that have no actions
• Better developer experience with a cleaner, more actionable toolkit list

Questions?

If you have questions or need support with any deprecated toolkit, reach out to our team or check our documentation.

Deprecation of is_local_toolkit Field and Removal of is_local Query Parameter

We’re cleaning up the Toolkits API by deprecating the is_local_toolkit response field and removing the is_local query parameter filter.

What’s Changing?

Response Field: is_local_toolkit (Deprecated)

The is_local_toolkit field in toolkit API responses is now deprecated. This field was originally intended to indicate whether a toolkit was local to a specific project, but it is no longer meaningful as no toolkits use this classification.

Affected Endpoints:

• GET /api/v3/toolkits - List toolkits
• GET /api/v3/toolkits/{slug} - Get single toolkit
• GET /api/v3/toolkits/multi - Get multiple toolkits

The field will continue to be returned in API responses for backward compatibility, but it will always return false. It is marked as deprecated: true in the OpenAPI specification.

Query Parameter: is_local (Removed)

The is_local query parameter filter has been removed from the following endpoints:

• GET /api/v3/toolkits
• GET /api/v3/toolkits/multi

This parameter was used to filter toolkits by their local status, but since no toolkits are classified as local, it served no practical purpose.

Impact on Your Code

If You’re Using the is_local Query Parameter

Before:

1
// This will no longer work
2
const toolkits = await fetch('/api/v3/toolkits?is_local=true');

After:

1
// Simply remove the is_local parameter
2
const toolkits = await fetch('/api/v3/toolkits');

If You’re Reading the is_local_toolkit Response Field

The field will continue to be present in responses but will always return false. You can safely ignore this field or remove any logic that depends on it.

Before:

1
const toolkit = await composio.toolkits.get('github');
2
if (toolkit.is_local_toolkit) {
3
  // This condition will never be true
4
  handleLocalToolkit(toolkit);
5
}

After:

1
const toolkit = await composio.toolkits.get('github');
2
// Remove is_local_toolkit checks - they're no longer meaningful