Discover available chat sources and AI models in one call.

Returns up to three sections:

• sources — every connector instance the org has wired up plus the synthetic knowledgeBase_<orgId> entry for the org's KB. Each item's id is exactly the value to put in pipeshub_chat's or pipeshub_search's apps filter.

• llmModels — chat / generation models. Each item's modelKey is the value to pass on pipeshub_chat / pipeshub_search as modelKey. Pick isDefault: true unless the user asks for a specific model.

• embeddingModels — vector embedding models (only fetched when explicitly requested via include).

Call this once at the start of a session and cache the result — sources and models change infrequently. sources and llmModels are returned by default; pass include to override.

Ask a question, get an answer grounded in the org's indexed data with citations. It reads a few retrieved passages — never a whole document, never a complete list.

Three questions this tool gets WRONG. Check them first:

• Structure — "what's under this epic?", "which pages are in this space?", "what links to this ticket?", "what's in this folder?" → pipeshub_get_record_content mode:"navigate". Ranking cannot see how records relate.

• Exhaustive — "how many X?", "list ALL the Y", "every Z" → mode:"navigate", which reports the group's real total. This tool undercounts and will not say so.

• One named document — summarize it, extract from it, what does it say about X → pipeshub_search for the recordId, then mode:"content".

Everything else about the org's knowledge belongs here: policies, processes, decisions, history, "what do we know about X", and any question spanning several documents.

Internal search (default, chatMode: "internal_search"): the user's documents, files, knowledge base, company policies — anything in their PipesHub-indexed sources (Drive, Box, Confluence, Slack, Gmail, Jira, the org's KB, ...).

Web search (chatMode: "web_search"): current events or public information unlikely to be in the org's knowledge base.

Both are plain-chat modes. Agent chat — pass an agentId from pipeshub_agents — runs against that agent's own prompt, tools and knowledge; quick is its only mode, requires the agentId, and is sent automatically.

• "What's our policy on Y?" → pipeshub_chat (internal_search)

• "What's in the news about Z?" → pipeshub_chat (web_search)

• "Find / locate the file named X" → pipeshub_search (then pipeshub_download_record if the user wants the bytes).

Conversation lifecycle — one tool, both start and continue:

• First turn: omit conversationId. The server creates a new conversation; capture conversationId from the response.

• Follow-up turn: pass the conversationId from the previous response. Server-side context is preserved — do NOT replay earlier messages, and filters is ignored on follow-ups (set once at creation).

Only re-omit conversationId (start a fresh conversation) when the user explicitly asks to start over / clear context.

The response contains the AI's answer plus citations. To download a cited document, take citations[*].recordId and call pipeshub_download_record.

Vector / semantic search across the org's indexed documents.

Use this when the user wants to LOCATE a document — by name, topic, or a phrase to grep for — and to resolve it to a recordId. For open-ended questions across many documents, use pipeshub_chat instead, which does the retrieval internally and grounds the answer in citations.

Typical uses:

• Resolve a doc name / topic into a recordId for pipeshub_get_record_content — step 1 of any full-document task (summarize, extract, review, "what does the doc say?").

• Resolve a filename / phrase into a recordId for pipeshub_download_record.

• Show the user a ranked list of matching files when they ask "find / search for X".

Not for structural questions — what is under this epic, which pages are in this space, what links to this ticket. Ranking by content cannot show how records relate; use pipeshub_get_record_content mode:"navigate".

A ranked sample, never a complete list. Hits are the top-scoring blocks from the best-matching records — not all blocks of any record, and not every record that matches. Never count them to answer "how many" / "all" / "every"; navigate the record group instead, which reports its real total.

The response is trimmed to one row per hit: { recordId, recordName, score, snippet, mimeType, webUrl, ... }. Highest score first; multiple hits may share the same recordId (different blocks of the same record).

When presenting results to the user, link each record using its webUrl (when present).

Stream the binary content of a single record from PipesHub.

Typical sources for the recordId:

• A chat citation: pipeshub_chat response → citations[*].recordId.

• A search result: pipeshub_search response → hits[*].recordId / uniqueRecords[*].recordId.

Response Content-Type is forwarded from the upstream service — application/pdf, application/octet-stream, etc. Binary content is returned base64-encoded; text content is returned inline.

Three operations on the org's records. Pick by what you hold:

mode:"lookup" — a URL, issue key (PA-1787), or external ID → its recordId plus the record's metadata mode:"navigate" — a question about structure: what is under X, what links to Y → browses the hierarchy mode:"content" — a recordId, and you need the document's COMPLETE text

mode:"content" (default) — the only way to see a document's complete text. Use it whenever missing part of the document could make the answer wrong: summarize, extract or list ALL of something, check whether or where a doc mentions X, review, or compare named docs. pipeshub_chat cannot do these — it never sees a whole document.

Judge by the user's INTENT, not their keywords: "what's this doc about?", "walk me through the report", "anything in here about Y?" are all full-content tasks. Get the recordId from a pipeshub_search top hit, a chat citation, or mode:"lookup".

Returns one content string: a metadata header (title, source, key fields, pre-generated summary) then the full parsed text. A record with no extractable content returns the literal No record found. Use pipeshub_download_record only for the original file bytes.

mode:"navigate" — browse the hierarchy: RecordGroup (project / space / drive / folder) → Record (epic / story / page / file) → children, with breadcrumbs, related links and record IDs.

Use it when the question depends on structure rather than wording: what is under this epic, which pages sit in this space, what is linked to this ticket, what is in this folder — and every "how many" / "all of" / "every" question. Search ranks by content; only this shows how records relate, and only this gives a count you can trust.

Omit nodeId for a flat listing of everything reachable, most recently updated first — the usual starting point. A URL, an issue key, or a pipeshub_sources id also works and resolves automatically.

Pass depth:2 or depth:3 to see several levels in ONE call — an epic's stories AND their subtasks, a space's pages AND their children — instead of one call per level. Use it whenever the question needs an overview of a hierarchy rather than a single node.

Opening a record also prints that record's own metadata — for a ticket, status, assignee, priority and dates — so a question about one record is often answered by this call alone. It returns no document text; for that, re-call with mode:"content".

Returns Path breadcrumbs, the current node's metadata, a children listing carrying record_id= or node_id= per row plus the group's total (Children 1-50 of 61), Related cross-references, and a Next: line. One page is usually every child, so only pass page:2 when that Next: line says more exist.

mode:"lookup" — turn an external reference into a recordId, the first step whenever the question names one. Returns that record's metadata (for a ticket: status, assignee, priority, dates) plus its recordId, which mode:"navigate" takes to list what is under it and mode:"content" takes to read it.

Handles Jira keys and URLs, Confluence, Drive, Slack permalinks, Linear, Notion, ServiceNow sys_id, SharePoint, Gmail/Outlook, and any connector whose records index a web URL. Resolution searches ALL connectors you can access, regardless of any source filter you used elsewhere.

A miss is a 200 with empty matches and the input echoed in not_found_identifiers — that may mean no-access, not non-existence. Use mode:"navigate" to confirm the record exists before telling the user it does not. If ambiguous is true, pick from matches rather than taking the first.

Navigate and lookup return a rendered text view whose closing Next: line names the exact follow-up call — follow it. When presenting a record, link it using the Web URL from its metadata header (when present).

Look up people, groups, and teams in PipesHub. One tool with five actions — pick the right action:

• whoami — who is the caller? Use this whenever you need the authenticated user's own id, email, or full name (e.g. before get_user on themselves). Errors if the credential is expired or revoked.

• list_users — search / page through org users.

• get_user — full User document for one user (requires userId).

• list_groups — list user groups with userCount.

• list_my_teams — teams the caller belongs to, with capability flags (canEdit / canDelete / canManageMembers).

Output shape varies by action; see each action's docs above.

List the PipesHub agents configured for this org, each with its capabilities.

Agents are specialized assistants (custom system prompt, tools, knowledge scope). To converse with one, take its agentId and pass it to pipeshub_chat's agentId argument.

Each agent is returned as: { agentId, name, description, systemPrompt, startMessage, tags, webSearch, isActive, toolsets, knowledge }.

• toolsets — what the agent can DO: each { name, tools } where name is the connector (e.g. jira, gmail) and tools are the runnable tool ids (e.g. jira.create_issue, gmail.send_email).

• knowledge — what the agent can READ: each { name, type } (e.g. Confluence-2 / Confluence).

Route on toolsets/knowledge, not the name — names and descriptions are often generic or misleading. Match the request to the agent whose tools can actually perform it (e.g. "create a Jira ticket" → the agent whose toolset is jira and whose tools include jira.create_issue). If NO agent has a tool for the requested action, say so — don't force an unrelated agent.

The list may be empty (no agents configured). For plain Q&A when no specific agent is needed, use pipeshub_chat WITHOUT agentId and pick a chatMode: internal_search (org's indexed knowledge) or web_search (live web). Use agentId everywhere an agent is referenced.