Webhook Assistant Context

dps

Enable Kagi users to bind custom webhooks to assistant configurations. This feature allows the LLM to dynamically fetch and integrate external data, providing rich, personalized context.

Two Integration Methods:

Initial Conversation Context: Configure a webhook within a custom assistant. Kagi automatically triggers it at the start of a new conversation, injecting the returned data (e.g., daily health stats) into the LLM's initial prompt.
On-Demand via Slash Commands: Define custom slash commands (e.g., /myhealth, /financestatus) bound to specific webhooks. Typing the command triggers the webhook, injecting up-to-the-minute data into the current conversation context.

Key Benefits

This feature offers significant advantages for any Kagi user seeking more powerful and personalized AI assistance:

Enhanced Personalization: Delivers highly relevant, actionable advice and information based on the user's unique, real-time data.
Increased Efficiency: Automates the injection of context, eliminating manual data transfer and reducing cognitive load, allowing users to focus on core tasks.
Data Control & Privacy: Users maintain full control over their data by hosting their own webhooks and defining precisely what information is shared, aligning with privacy-first principles.
Flexible Integration: Empowers users to connect Kagi with a wide array of personal data sources, from health trackers to productivity tools, leveraging existing systems.
Streamlined Workflows: Integrates external information seamlessly into conversations, making Kagi a more central and intelligent hub for personal and professional tasks.

Why This Over MCP

Purpose-fit: Webhooks excel at simple context injection (startup or slash-command). MCP is designed for full tool ecosystems and is overkill for this use case.
Lower integration cost: A webhook is just an HTTP endpoint. MCP typically requires standing up a protocol server, capabilities, schemas, and session management.
Broader compatibility: Works with any HTTP-accessible source today; MCP support varies across clients and ecosystems.
Tighter data control: Push only the exact payload when needed; MCP integrations often expose broader interfaces and capabilities than necessary.
Performance & reliability: Single, stateless calls with straightforward retries/timeouts; MCP adds session/streaming layers and handshake overhead.
Easier security and auditing: Standard HTTP auth and logs; simpler permission model than protocol-specific capability grants.
Incremental path: Start with webhooks now; wrap the same endpoint behind an MCP server later if deeper tool integration is warranted.

fxgn

Could you please provide specific benefits and usecases you may have for this instead of an overly long AI generared request with zero specifics?

I'm not sure this would be that useful for most people. Renting a server an hosting your own webhook on it just to make Assistant able to request some data. It can already access regular HTTP URLs anyway.

dps

fxgn Well, just because AI helps generate some of it doesn’t mean you shouldn’t read any of the thoughts, as the ideas it’s sharing are from me 🙂 if you all want shorter feature requests, maybe the forum shouldn’t ask the author 10 questions for one simple idea!

MCP is cumbersome and overkill for most users. HTTP requests doesn’t consider majority of use cases for private data, locked behind an API key of sorts.

If a user has a health and fitness custom assistant. A couple of webhooks from their health and fitness data providers can be called dynamically via a slash command, to further strengthen the LLMs answer.

This is deterministic feature for pulling in relevant context. One of AIs biggest weak points.