Skip to main content
Glama
pipeshub-ai

PipesHub MCP Server

Official
by pipeshub-ai
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Hybrid

pipeshub_get_record_content

Read-onlyIdempotent

Retrieve the complete text of a record by ID to summarize, extract all mentions, or review full document content.

Instructions

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).

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
modeNo`content` (default) reads a record's full text by `recordId`. `lookup` resolves a URL / issue key / external ID to a recordId. `navigate` browses the knowledge graph tree.content
pageNoPage number, 1-indexed.
depthNoLevels of descendants to return in one call. Above 1, the listing is a flat list of all descendants down to that level rather than only direct children, and each row carries its own `level`.
limitNoChildren per page. The minimum is 50 — smaller values are rejected rather than silently raised.
nodeIdNoThe node to open. Take it from a `record_id=` or `node_id=` shown in a previous navigate or lookup response, from a search hit's `recordId`, or from a `pipeshub_sources` id — a KB or connector id opens that source directly. Omit it entirely for the flat listing of everything reachable, newest first — the usual starting point. A URL or an issue key such as `PA-1787` also works: it is resolved to its record automatically, so no separate lookup is needed.
recordIdNoRecord identifier — usually a UUID for connector-sourced records or a 24-character ObjectId for uploaded records. Get it from a chat citation (`citations[*].recordId`) or from a `pipeshub_search` hit. Required when `mode` is `content`.
nodeTypesNoRestrict children to these node types, e.g. `["record", "folder"]`.
identifiersNoThe reference(s) to resolve: a URL, an issue key such as `PA-1787`, or a bare external system ID. Paste each exactly as you found it — tracking parameters and fragments are handled. Pass a single string, or an array of up to 10 to resolve them in one call. Required when `mode` is `lookup`.
createdAfterNoFilter children by source creation time. ISO 8601 `YYYY-MM-DD`, or a full datetime that MUST carry a timezone offset — a naive datetime is rejected rather than assumed to be UTC.
connectorNameNoOptional hint that prioritises resolution order, e.g. `JIRA`, `CONFLUENCE`, `GOOGLE_DRIVE`, `SLACK`. It cannot widen the search beyond the connectors you can already access. Useful on a retry when a lookup came back empty.
createdBeforeNoFilter children by source creation time. `YYYY-MM-DD` is inclusive of the whole day.
modifiedAfterNoFilter children by source modification time. Same formats as `createdAfter`.
modifiedBeforeNoFilter children by source modification time. Same formats as `createdBefore`.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv2.3.3

TDQS

A5/5.0
Behavior5/5

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

Beyond annotations (readOnlyHint=true), the description discloses return formats, edge cases ('No record found', '200 with empty matches', 'ambiguous' handling), resolution behavior ('searches ALL connectors'), pagination triggers ('only pass page:2 when Next: line says more'), and rendering details. 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.

Conciseness5/5

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

The description is lengthy but every sentence adds practical value for a tool with three modes and 13 parameters. It is front-loaded with a mode summary, uses clear section headers, and avoids filler. The structure mirrors the decision flow an agent needs.

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 no output schema, the description fully explains return values for all modes, prerequisites (like obtaining recordId), error/edge behaviors, and sibling routing. Nothing an agent needs to invoke correctly is missing, given the rich schema and annotations.

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

Parameters5/5

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

Although schema coverage is 100%, the description adds significant contextual meaning: explains how to obtain nodeId, when to omit it, how depth affects output, how identifiers resolve automatically, and how to interpret returns like 'Children 1-50 of 61'. These are usage patterns beyond schema field definitions.

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 clearly states the tool performs three operations (lookup, navigate, content) on the org's records, with each mode named and explained. It explicitly differentiates from siblings (pipeshub_chat cannot see whole docs, pipeshub_download_record for raw bytes), making purpose unambiguous.

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?

Provides explicit when-to-use guidance per mode, including intent-based examples ('what's this doc about?' → content) and exclusions ('Use pipeshub_download_record only for the original file bytes', 'pipeshub_chat cannot do these'). Also tells when to pass depth and how to get recordId, leaving no ambiguity about selection.

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