Skip to main content
Glama
pipeshub-ai

PipesHub MCP Server

Official
by pipeshub-ai
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Hybrid

pipeshub_chat

Ask questions and get answers grounded in your organization's indexed data with citations. Search internal sources or the live web, and continue follow-up conversations.

Instructions

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.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
queryYesThe user's question or message for this turn.
agentIdNoOptional PipesHub agent to converse with — the `agentId` from `pipeshub_agents`. When set, this turn runs against that agent's configuration (prompt, tools, knowledge). On follow-up turns pass the SAME `agentId` together with the `conversationId` returned by the previous call. Omit for a plain (non-agent) conversation. If unsure which agent to use, call `pipeshub_agents` first to see the options.
filtersNoSource scoping for retrieval. Pass `apps` ids from `pipeshub_sources`. Only meaningful on the FIRST turn (when starting a new conversation).
chatModeNoResponse strategy. The valid values depend on whether `agentId` is set: - WITHOUT `agentId` (plain chat): `internal_search` — answer from the org's indexed knowledge (default) — or `web_search` — answer from the live web. - WITH `agentId` (agent chat): `quick` is the only supported mode and is sent automatically, so this argument can be omitted.
modelKeyNoModel id to use (from `pipeshub_sources` `llmModels[*].modelKey`). Defaults to the org's default LLM.
modelNameNo
conversationIdNoExisting conversation id to continue. Omit on the FIRST turn; on every subsequent turn pass the `conversationId` returned by the previous call. Server-side message history is preserved — do NOT replay prior messages.
modelFriendlyNameNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv2.3.3

TDQS

A4.8/5.0
Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

The description discloses critical behavioral traits beyond the annotations: it reads only a few retrieved passages, never a whole document or complete list; it undercounts exhaustive queries and won't say so; conversation lifecycle behavior (omit conversationId on first turn, pass it on follow-ups, filters ignored on follow-ups); and how to download cited documents. The annotations declare readOnlyHint=false, openWorldHint=true, idempotentHint=false, destructiveHint=false, and the description adds substantial context about what the tool does and doesn't do. No contradiction with annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is long but every section earns its place: the three-wrong-questions list, the mode explanations, the conversation lifecycle, and the citation download pointer. It's well-structured with bold headers and bullet-like formatting. It could be slightly more concise, but the density of actionable information justifies the length. The most critical routing information is front-loaded.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a complex tool with 8 parameters, nested objects, no output schema, and multiple modes, the description is remarkably complete. It covers the three modes (internal_search, web_search, agent chat), the conversation lifecycle, the filters scoping, the citation download flow, and the routing to siblings. The only minor gap is that it doesn't describe the exact response format beyond 'answer plus citations', but the description explicitly tells the agent how to use citations, which is what matters for follow-up actions. No output schema exists, so the description carries the burden, and it does so thoroughly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 75%, so the schema already documents most parameters. The description adds meaning beyond the schema by explaining the conversation lifecycle (omit conversationId on first turn, pass it on follow-ups, filters ignored on follow-ups), the chatMode semantics (internal_search vs web_search vs quick with agentId), and the filters behavior (only meaningful on first turn, apps ids from pipeshub_sources). This is valuable semantic context that the schema alone doesn't provide. The description doesn't cover modelKey/modelName/modelFriendlyName, but those are self-explanatory and the schema covers them.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description opens with a specific verb and resource: 'Ask a question, get an answer grounded in the org's indexed data with citations.' It immediately distinguishes itself from siblings by naming the three question types it gets wrong and routing them to pipeshub_get_record_content and pipeshub_search. This is a clear, specific purpose statement that differentiates the tool from its siblings.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides explicit when-to-use and when-not-to-use guidance. It lists three categories of questions the tool gets wrong and directs the agent to the correct alternative for each. It also gives concrete examples ('What's our policy on Y?' → pipeshub_chat internal_search; 'Find / locate the file named X' → pipeshub_search). This is exemplary usage guidance.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Deploy Server

Other Tools