Have something to say?

Tell us how we could make the product more useful to you.

Microsoft sign in and Entra for HQs and Apps

We're aware Chipp supports Bring‑Your‑Own‑Auth (a custom-hosted login page that transfers a token to Chipp), but that requires us to build and host our own auth layer. What we're asking for is native Microsoft/Entra integration, which we'd break into three levels — ordered from most to least needed: "Sign in with Microsoft" (most needed): A generic Microsoft sign-in option available to users of the HQ and Apps, similar to the existing Google sign-in option — no connection to our specific Entra tenant required, just a standard Microsoft account login option alongside existing sign-in methods. Direct Entra tenant connection for group-based access control and provisioning: Ability to connect our specific Entra tenant to Chipp HQ and individual apps for more granular control — specifically, mapping Entra/AD groups to determine which apps a user can see and access, and potentially using Entra for user provisioning (e.g., SCIM or a similar sync mechanism) so access can be managed centrally from our directory rather than manually inside Chipp. Note: we use an RBAC structure in AD where users are members of role-based security groups, which are then nested inside resource-based security groups (rather than being added to resource groups directly). If group mapping is supported, it would need to account for nested/transitive group membership, not just direct membership, in order to work with our setup. Multi-tenant support (lowest priority): Ability to connect more than one Entra tenant to the same Chipp workspace, since our organization spans multiple tenants. This is something we could work around in the near term if needed. We see these as three levels of the same overall request, and would value each one, but wanted to be clear about relative priority in case they're not all feasible at once.

Peter Knudsen 5 days ago

💡

Feature Request

MCP error: add_url_source via MCP never triggers crawler (sources stuck PROCESSING)

Date: 2026-04-05 MCP Server: Chipp (build.chipp.ai/mcp, streamable-http transport) MCP Client: Claude Code v2.1.92 (Anthropic CLI, macOS) Steps to reproduce Call add_url_source via MCP to add a URL-based knowledge source: { "appId": 10041051, "url": "https://portal-conneva.vercel.app/api/mosaic/knowledge/index.html", "crawlAllLinks": true } Result Source is created successfully and returns a source ID (e.g., dd18f40d-5de9-46a1-a1c8-2a41a9686237). However, the source remains in PROCESSING status indefinitely — the crawler never picks it up. Calling get_crawl_progress on the source returns: { "error": { "code": "INTERNAL_ERROR", "message": "Failed to connect before the deadline" } } Expected Source transitions through PENDING → PROCESSING → COMPLETED as the crawler fetches and indexes the content. This is the behavior observed when adding the same URL via the Chipp dashboard. Root cause evidence Dashboard-added sources crawl fine. The same URL was added manually through the build.chipp.ai dashboard and crawled to COMPLETED status successfully. Two individual topic URLs were also added via dashboard and indexed correctly. MCP-created sources never start crawling. Multiple sources created via add_url_source MCP tool remain stuck at PROCESSING. No crawl activity is observed. The crawler itself is healthy. Dashboard-initiated crawls complete normally, confirming the crawler service is running. The issue is that MCP-created sources are not being enqueued for crawling. get_crawl_progress also fails for MCP-created sources with a "Failed to connect before the deadline" error, suggesting the crawl was never initiated (no Temporal workflow to query). Tested multiple times across different sessions and URLs — consistently reproducible. Workaround Add sources manually via the build.chipp.ai dashboard instead of the MCP add_url_source tool. Environment MCP Server: Chipp (build.chipp.ai/mcp, streamable-http, OAuth 2.0 + PKCE) MCP Client: Claude Code v2.1.92 (Anthropic CLI, macOS darwin) All other MCP tools (app management, list_knowledge_sources, delete_knowledge_source, custom actions, system prompt, branding) function normally for this workspace and app.

Mark Carlson 4 months ago

1
🐛

Bugs

MCP bug: search_documentation fails with Postgres connection error

Date: 2026-03-22 MCP Server: Chipp (build.chipp.ai/mcp, streamable-http transport) MCP Client: Claude Code (Anthropic CLI, macOS) Steps to reproduce Call search_documentation with any query: { "query": "add_document_source file upload base64" } Result { "error": { "code": "INTERNAL_ERROR", "message": "connect ECONNREFUSED 127.0.0.1:5432" } } Expected Returns relevant documentation excerpts. Root cause evidence The error connect ECONNREFUSED 127.0.0.1:5432 indicates the documentation search handler is attempting to connect to a PostgreSQL instance on localhost:5432. This suggests the docs search feature uses a local or sidecar Postgres database that is not running in the MCP server's deployed environment. Other MCP tools that use a different database connection (app CRUD, knowledge sources, custom actions) all work correctly, so this appears to be a database configuration issue specific to the documentation search feature. Tested twice in the same session — consistently fails with the same error. Environment MCP Server: Chipp (build.chipp.ai/mcp, streamable-http, OAuth 2.0 + PKCE) MCP Client: Claude Code (Anthropic CLI, macOS darwin) All other MCP tools (app management, knowledge sources, custom actions, system prompt, branding) function normally for this workspace and app.

Mark Carlson 4 months ago

🐛

Bugs

MCP error: add_document_source fails with GCS credential error

Date: 2026-03-22 MCP Server: Chipp (build.chipp.ai/mcp, streamable-http transport) MCP Client: Claude Code (Anthropic CLI, macOS) Steps to reproduce Call MCP add_document_source tool with any file. Minimal example: { "appId": 10041051, "files": [ { "fileName": "test-topic.md", "content": "IyBUZXN0IFRvcGljCgpUaGlzIGlzIGEgdGVzdCBkb2N1bWVudCBmb3Ig dGhlIGtub3dsZWRnZSBiYXNlLg==" } ] } The base64 content decodes to: Test Topic This is a test document for the knowledge base. Result { "error": { "code": "INTERNAL_ERROR", "message": "The incoming JSON object does not contain a client_email field" } } Expected File uploads and begins processing (PENDING → PROCESSING → COMPLETED). Root cause evidence The error message "The incoming JSON object does not contain a client_email field" is produced by the Google Cloud Node.js client library (google-auth-library) when parsing a service account key file. It is thrown when the GoogleAuth constructor receives a credentials object missing the required client_email property. This suggests the add_document_source code path initializes a Google Cloud Storage (GCS) client to upload the decoded file, but the service account JSON key is either missing, malformed, or not configured in the MCP server's runtime environment. Evidence that other knowledge source tools work (same app, same session) The failure is isolated to the file upload code path. All other MCP tools — including other knowledge source tools (add_url_source, list_knowledge_sources, get_knowledge_source, delete_knowledge_source, refresh_knowledge_source) — work correctly for the same app and workspace. Environment MCP Server: Chipp (build.chipp.ai/mcp, streamable-http, OAuth 2.0 + PKCE) MCP Client: Claude Code (Anthropic CLI, macOS darwin)

Mark Carlson 4 months ago

🐛

Bugs