MCP Tools Inventory

Zeeq provides:
- Canonical documentation to produce high quality code
- Code review tools to run expert code reviews efficiently.

Prefer working in known partition to scope tool usage.

<session_bootstrap>
Call `list_documents` once near session start / first research for the compact knowledge index; use `list_libraries` only when library scope is unknown.
</session_bootstrap>

<research_flow>
Zeeq has a library of canonical documentation available
zeeq:// path prefixes are requests to use the Zeeq MCP to read a document in the library

1. `search_sections` for guidance/rationale/constraints/edge cases;
2. `search_code_snippets` for local patterns/boilerplate/tests/API shapes;
3. `read_document_by_path` for full docs context;
4. `search_documents` for efficient full-text search.
</research_flow>

<code_review_usage>
When code changes are ready, use the `expert_code_review` tool to get an expert review grounded in Zeeq documentation
The tool is context efficient; dump git diffs and upload to a signed URL then trigger a review job
Reduce mistakes and blind spots by relying on external reviewers
</code_review_usage>

Pay attention to tool trigger conditions <tool_name.triggers> and <tool_name.flow> to know when and how to use the tool effectively.

A human reviewer has created a saved cart of reviewer findings that needs to be fixed.
This tool retrieves the full cart of findings that should be verified and addressed.

<get_cart_findings.triggers>
- The user pasted instructions containing a cart ID and asked you to act on it
- The user presents an ID that is a 6 letter adjective, 4 letter noun, and 10 character nanoid (e.g. snappy-lake-a1b2c3d4e5)
- You need the full body of the code reviewer findings in order to verify and fix them
</get_cart_findings.triggers>

Use this tool to fetch the full cart of findings.
Work with your local user to assess each finding and decide on a course of action.
Process each finding, one-by-one and present a sensible default along with other options for verified fixes.

Retrieves expert code-review findings for the newest completed review matching a repository
and either a pull request number or branch name.

<get_review_findings.triggers>
- The user asks for review findings for a PR
- The user asks for review findings for a branch
- The user asks for review findings above a specific severity level
- The agent knows the current repository and branch or PR number and needs the latest review findings
</get_review_findings.triggers>

Provide ownerQualifiedRepoName in owner/repo form, such as zeeq-ai/zeeq.
Provide either pullRequestNumber or branch.

minimumLevel is optional. Supported values are CRITICAL, MAJOR, MINOR, SUGGESTION, and COMMENT.
Empty means all findings. COMMENT is the lowest level and also means all findings.
The filter is inclusive: MAJOR returns CRITICAL and MAJOR findings; MINOR returns
CRITICAL, MAJOR, and MINOR findings.

Use once near the start of an agent session, or before first knowledge-base library
research, to discover what canonical documents are available.

Returns a compact table-of-contents / dense index of KB documents by partition,
including paths and keywords. This helps map the available expert guidance before
planning, researching, implementing, debugging, or reviewing code.

<list_kb_documents.triggers>
- Start of session, first KB lookup, project onboarding, or repo exploration
- Need to know what docs, guidance, best practices, references, or research sources exist
- Before choosing which KB document to read or which semantic KB search to run
- Explicit trigger words like: check documents, check library, refer to docs, read KB, and similar
</list_kb_documents.triggers>

Call this only once per session and reuse the result unless the document
library or target partition may have changed.

Use to read the full markdown content of a specific document in a document library.

Use `list_documents` to get the list of documents available in the library.

<read_document_by_path.triggers>
- You identified a document path from `list_documents` or `search_documents` and need its full content
- zeeq:// prefixed paths ending in `.md` are explicit requests to the Zeeq MCP to read a document in the library
- A `search_documents` result points to a document you have not read yet
- You need the complete document rather than the ranked snippets a search returns
- Planning, implementing, or reviewing work that requires comprehensive guidance from a specific document
</read_document_by_path.triggers>

Use `list_documents` to discover available paths.
Do NOT re-read a document you already retrieved in this session.

Efficient retrieval of indexed, canonical code samples.

Use this when planning/researching, about to act, or reviewing code where a
canonical project-specific code pattern may exist.

Search indexed docs for reference snippets, preferred API shapes, local
idioms, boilerplate examples, tests, endpoint patterns, storage patterns,
logging/telemetry patterns, UI state patterns, and migration examples.

<search_kb_code_samples.triggers>
- Planning/researching: identify implementation shape, files, patterns, or test strategy
- About to act: implement, refactor, wire services, add tests, or fix failures
- Reviewing code: compare against canonical snippets, API shape, or local idioms
- Adding endpoints, tests, migrations, storage code, service wiring, logging, telemetry, integrations, or UI state
- Knowing task intent but not the repo's exact API shape, local idiom, or layer pattern
- When local file has conflicting patterns or inconsistencies and canonical conventions are needed
</search_kb_code_samples.triggers>

Query with implementation intent plus language, framework, layer, API names,
known symbols, entities, activity (logging, exception handling, database, etc.), and adjacent terms.

Prefer this over remembered approaches or general model knowledge for
non-trivial code. Use search_sections first when you need design rationale
or constraints. Skip it for tiny edits where no reusable pattern or
implementation convention is involved.

Use to find the most relevant documents in a manual in the document library.
These documents help write correct code; they are repository guidance and best practices.

<search_documents.triggers>
- Need to find guidance for key topics like logging, telemetry, error handling, coding practices, feature areas, technologies
- The exact document path is not known and a topical search is needed to find the right content
- Narrowing a large library to the documents relevant to a task before reading them
</search_documents.triggers>

Use `list_libraries` to find the library name and `read_document_by_path` to read a full result.
Spaces OR terms together (broadens) — every keyword is an independent alternative, ranked by how many/how well terms match.
Prefer this over `list_documents` when keywords and topics are already at hand and you need best practices or guidance.

Efficient retrieval of indexed sections of canonical guidance.

Use this when planning/researching, about to act, or reviewing code where
repo-specific prose guidance may affect the answer.

Search canonical knowledge-base sections for conceptual guidance,
constraints, rationale, tradeoffs, edge cases, and best practices.

<search_kb_sections.triggers>
- Planning/researching: choose an approach, draft a plan, understand context
- About to act: implement, refactor, debug, explain, or recommend
- Reviewing code: check canonical rules, conventions, rationale, or edge cases
- Code samples are too narrow; contextual explanation is needed
</search_kb_sections.triggers>

Query with task intent and relevant key phrases for semantic matches

Prefer this over reading whole documents when you need focused guidance. Use
search_code_snippets instead when you need concrete code patterns.