Skip to main content
Glama
jgravelle

jdocmunch-mcp

by jgravelle
OverviewSchemaRelated ServersScoreDiscussions
Python
Local

search_sections

Read-only

Locate relevant documentation sections using hybrid lexical and semantic search. Returns summaries so you can focus on the most pertinent content.

Instructions

Search sections by relevance. Hybrid (BM25 lexical + semantic embedding) fusion when the index was built with use_embeddings=true; falls back to lexical-only otherwise. Returns summaries only — use get_section for full content.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
repoNoRepository identifier
roleNoOptional v1.19+ role filter. Values: concept, tutorial, how_to, reference, api, example, troubleshooting, changelog, faq, other.
tagsNov1.45+ — restrict to sections whose Section.tags contains every listed tag (AND semantics). Case-insensitive.
queryYesSearch query
rolesNov1.52+ — restrict to sections whose metadata.role matches ANY listed role (positive OR-match). Differs from singular `role` (which is exact). Case-insensitive.
dedupeNov1.34+ — collapse near-duplicate sections to a single representative based on the v1.34 cluster sidecar. _meta.deduped reports suppressed member ids.
fieldsNov1.121+ — explicit per-row field whitelist (e.g. ['id','title','doc_path','_score']). Wins over compact. `id` is always returned.
compactNov1.121+ — drop per-row fields a caller can't act on (repo, parent_id, children, byte_start/byte_end, content_hash, inline_code, references; plus empty tags and a summary identical to the title). Per-row _freshness is kept only when it isn't 'fresh'. ~40% fewer bytes per result. Default off — the full row is unchanged.
profileNov1.32+ — task-aware retrieval profile. install/debug/explain/api each boost a small role set so matching sections rank ahead. Explicit role= overrides.
doc_pathNoOptional: limit search to a specific document
semanticNonull/omit (auto — hybrid when embeddings exist), true (force hybrid), false (force lexical-only). Zero performance cost when the index has no embeddings.
max_levelNov1.44+ — restrict to sections at heading level <= this. Inclusive. Stacks with min_level.
min_levelNov1.44+ — restrict to sections at heading level >= this. Inclusive.
path_globNov1.36+ — fnmatch glob restricting results to matching doc_paths (e.g. 'api/**/*.md'). Stacks with doc_path.
repo_groupNov1.26+ — fan out across the named repo group (defined via define_repo_group). When set, the per-repo `repo` arg is ignored; results from each member repo are fused via RRF.
max_resultsNoMaximum number of results to return
exclude_tagsNov1.51+ — drop sections whose Section.tags contains ANY listed tag (negative ANY-match). Stacks with `tags`. Case-insensitive.
exclude_rolesNov1.52+ — drop sections whose metadata.role matches ANY listed role. Case-insensitive. Stacks with `roles` (the result must match an included role and not match any excluded role).
semantic_onlyNoSkip lexical scoring; rank purely by embedding cosine similarity.
snippet_bytesNov1.121+ — inline the first N bytes of each section's body as `snippet` so a confident top hit needs no get_section round-trip. UTF-8 safe (never splits a codepoint); `snippet_truncated: true` marks a cut section. 0 = off.
max_byte_lengthNov1.53+ — drop sections longer than this many bytes. Use to filter out oversized dumps. Stacks with min_byte_length.
min_byte_lengthNov1.53+ — drop sections shorter than this many bytes (byte_end - byte_start). Use to filter out stubs / one-liners.
min_quotabilityNov1.42+ — drop results whose v1.33 _quotability score is below this threshold (0–1). Stacks with min_answerability.
semantic_weightNoWeight (0.0–1.0) of semantic component in hybrid fusion. Lexical gets 1 - weight. Default 0.5.
min_answerabilityNov1.42+ — drop results whose v1.33 _answerability score is below this threshold (0–1). _meta.quality_filtered reports drop count.

Tool Definition Quality

A4.5/5.0
Behavior4/5

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

Annotations provide readOnlyHint=true, and the description complements this well by explaining the fallback behavior (hybrid→lexical when no embeddings), the summary-only output, and deduplication semantics. The semantic vs lexical distinction and zero-performance-cost claim for semantic=falsse adds useful behavioral nuance beyond annotations. Doesn't describe pagination or error behavior, but the schema coverage is strong.

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?

Two concise sentences that pack the retrieval mechanism, fallback behavior, and linkage to get_section. Zero waste — every clause earns its place. The description front-loads the core purpose before behavioral details.

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

Completeness4/5

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

For a 25-parameter search tool with 100% schema coverage and readOnly annotation, the description adequately frames the search mechanism and distinguishes from get_section. With no output schema, it doesn't document return structure beyond 'summaries only,' but the schema's field descriptions (e.g., _meta.deduped, snippet_truncated) provide substantial output detail. Slightly stronger return-shape guidance would push this to 5.

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?

Schema description coverage is 100%, so the schema carries the parameter documentation burden. The description nevertheless clarifies the top-level behavior (hybrid fusion, summary-only) that frames all parameters. The description doesn't need to repeat schema details; the framing it provides adds contextual value on top of complete schema docs.

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?

Description states a specific verb+resource ('Search sections by relevance') and clearly distinguishes behavior from get_section ('Returns summaries only — use get_section for full content'). The hybrid fusion explanation adds precision about how relevance is computed. Distinguishes from sibling tools like get_section and search_titles.

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 explains the retrieval mechanism (hybrid vs lexical-only fallback) and explicitly points to get_section as the alternative for full content. However, it doesn't specify when to prefer this over other search tools (search_titles, get_related_sections) or give scenario-based guidance for the many filtering parameters, though the schema descriptions compensate partially.

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

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/jgravelle/jdocmunch-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server