Log10x MCP Server

Official

by log-10x

Overview Schema Source Related Servers Discussions Admin

TypeScript

Local

Product Q&A from shipped docs

log10x_product_qa

Read-onlyIdempotent

Answers factual Log10x product questions from bundled docs using exact topic slugs or natural-language search, returning ranked results with canonical URLs for citation.

Instructions

Answer Log10x product questions from the docs that ship inside the MCP build (chunked + indexed at install time). Use whenever the user asks a factual product question: "what is the Receiver", "how is pattern_hash computed", "what data leaves my network", "does the Reporter modify data", instead of answering from training data. Inputs: topic for an exact docs-slug lookup (e.g. faq/security/data-protection), or query for natural-language TF-IDF search across those docs. category narrows search to one of faq / apps / engine / api / config / manage. max_results caps the result count (default 3). Output is a standard chassis envelope with found, ranked results (each carrying matched chunks + canonical_url), and similar_topics as a did-you-mean fallback. Link the canonical_url of each result used in the answer. The docs are shipped from config/mksite/docs at build time; in development the loader also honors LOG10X_PRODUCT_KB_PATH.

Input Schema

Name	Required	Description
`depth`	No	Response detail. "short" (default) returns a tight grounded answer plus citation metadata (topic + canonical_url, no section bodies) and offers a chained learn_more action per citation. "full" returns the matched section bodies for one specific page and is requested via the learn_more action the short response hands back (pass that action verbatim: `topic` + `depth: "full"`).
`query`	No	Natural-language query: prefer this for how-to / content questions. Examples: "what does the kustomize overlay patch", "how is pattern_hash computed". When `topic` is also set, ranks that page's sections by this query.
`topic`	No	Exact docs slug to fetch a known page. Example: "faq/security/data-protection" or "apps/receiver/deploy". For a multi-section page, ALSO pass `query` to get the asked-about section instead of the page intro.
`category`	No	Restrict results to one category. One of: faq, apps, engine, api, config, manage. Combines with `query`.
`max_results`	No	Cap on the number of results returned. Default 3.

Output Schema

Name	Required	Default
`data`	No
`tool`	Yes
`view`	No	summary
`images`	No
`actions`	No
`summary`	Yes
`warnings`	No
`truncated`	No
`next_cursor`	No
`render_hint`	No
`generated_at`	Yes
`schema_epoch`	Yes
`schema_version`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedv1.30.8Oct 15, 2026

changedInput schema / properties / query / description

Previous value: -"Natural-language query — prefer this for how-to / content questions. Examples: \"what does the kustomize overlay patch\", \"how is pattern_hash computed\". When `topic` is also set, ranks that page's sections by this query."New value: +"Natural-language query: prefer this for how-to / content questions. Examples: \"what does the kustomize overlay patch\", \"how is pattern_hash computed\". When `topic` is also set, ranks that page's sections by this query."

First observedv1.30.7Sep 11, 2026

TDQS

A4.2/5.0

Behavior4/5

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

Annotations already declare readOnlyHint=true, openWorldHint=false, and idempotentHint=true, so the safety profile is covered. The description adds useful behavioral context: docs are shipped and indexed at install time (static, not live), search is TF-IDF based, and results include a fallback via `similar_topics`. It doesn't contradict annotations and provides extra operational detail.

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 front-loaded with purpose and usage, and every sentence contributes something. However, it includes some implementation details (e.g., `config/mksite/docs`, `LOG10X_PRODUCT_KB_PATH`) that are not essential for an agent to invoke the tool, making it slightly longer than necessary.

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?

Given the tool's complexity (5 parameters, output schema, multiple modes), the description covers purpose, usage, parameter roles, output structure, and data source. It is self-contained and leaves no critical gaps for correct invocation, even though the output schema exists.

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

Parameters3/5

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

Schema description coverage is 100%, and the schema already documents every parameter with examples and interactions. The description mostly repeats those details (topic vs. query, category, max_results), adding little new meaning beyond what the schema provides. Baseline 3 is appropriate for high-coverage schemas.

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 states a specific verb ('Answer') and resource ('Log10x product questions from the docs that ship inside the MCP build'), and distinguishes itself from other tools by focusing on factual Q&A rather than diagnostics or configuration. An agent can easily tell this is for product documentation questions.

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

Usage Guidelines4/5

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

The description explicitly says 'Use whenever the user asks a factual product question' and gives multiple examples, plus an alternative ('instead of answering from training data'). It does not state when *not* to use it (e.g., for non-product questions), but the context is clear enough for selection.

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

Deploy Server