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

Answer Log10x product questions from the built-in docs corpus instead of training data. Look up exact doc slugs or run natural-language search, returning ranked, cited results.

Instructions

Answer Log10x product questions from the docs corpus that ships 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 the corpus. 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. Always cite canonical_url when surfacing an answer to the user. The corpus is shipped from config/mksite/docs at build time; in development the loader also honors LOG10X_PRODUCT_KB_PATH.

Input Schema

TableJSON 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

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

First observedv1.30.7Sep 11, 2026

TDQS

A4.6/5.0

Behavior4/5

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

Annotations already cover readOnly, idempotent, closed-world. The description adds unique operational context: the corpus ships inside the MCP build, is chunked/indexed at install time, and in development honors LOG10X_PRODUCT_KB_PATH. It doesn't cover staleness or size limits of the index, but with annotations handling safety it clears the bar.

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?

Front-loaded with the core purpose and examples, then a compact parameter-and-output block. It is dense but readable; a sentence about `depth`/`learn_more` chaining would have been a bigger win than the environment-variable aside, which is somewhat tangential for an agent.

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?

Despite 5 params and 0 required fields, the description gives the agent routing logic (topic vs query vs category), result shaping (max_results default), output envelope shape (found/results/similar_topics), and the citation obligation (always cite canonical_url). Output schema exists, but the description's summary of the envelope is still a net positive.

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 coverage is 100%, so the baseline is 3. The description adds value by stating the equivalence between topic-only vs topic+query ('ranks that page's sections by this query') and naming the exact enum values for `category` while explaining its filter semantics beyond the schema's list.

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?

States a specific verb and resource (answer Log10x product questions from the shipped docs corpus) and grounds it with concrete example questions. Distinguishes itself from data-oriented siblings like log10x_event_lookup and log10x_top_patterns by anchoring to a static docs corpus rather than live telemetry.

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?

Explicitly says to use it whenever the user asks a factual product question 'instead of answering from training data,' with rousing examples. It also explains when to pick `topic` (exact slug) vs `query` (natural-language search), which is the key routing decision.

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

Deploy Server