Skip to main content
Glama
Bluezeamer

PrecisionContextEngine

by Bluezeamer

pce_query

Locate code with natural-language questions about architecture, modules, entry points, and call chains. Get candidate files and file:line references to narrow your search before reading.

Instructions

Purpose: The primary tool for codebase navigation and understanding. Best suited for project-level understanding, architecture overviews, major module responsibilities, entry points, main call chains, candidate file scopes, and overall project/module comprehension. When to use: Use when the target location is unclear. When you do not know which file contains the information, need to understand what the project or a subsystem does, need a rough architecture or module-level picture, want to find entry points / main call chains / module responsibilities, or need to narrow down the search scope — use this tool first. Do NOT manually traverse directories, broadly inspect the repo, or batch-read files before trying pce_query. Best practice: Prefer describing your question in natural language rather than just giving exact identifiers. This tool is especially appropriate for questions like what the project does, how a subsystem is organized, where a feature lives, or which modules participate in a workflow. You can request file:line references, name_path, candidate file lists, call chain summaries, or results grouped by module. Avoid: When you already know the exact file or exact identifier and only need to view local implementation or do exact string matching, pce_query is not necessary. If the target is already clear and the task becomes 'what will be affected by changing it', switch to pce_impact instead.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
queryYesNatural language question, e.g. 'Where is the entry point for authentication logic?'

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A4.7/5.0
Behavior4/5

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

There are no annotations, so the description carries the behavioral burden. It explains the tool is exploratory/navigational, accepts natural-language questions, and can return structured navigation artifacts like file:line references, name_path, candidate file lists, call chain summaries, or grouped results. It does not explicitly state whether the operation is side-effect-free, but the read-only intent is strongly implied.

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 longer than average but uses labeled sections (Purpose, When to use, Best practice, Avoid) that make it scannable and front-loaded. A little redundancy exists between 'Best suited for...' and 'especially appropriate for...', but every paragraph adds actionable guidance.

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?

With no output schema, the description covers what the tool can return and what kinds of questions it answers. It also covers exclusions and sibling routing. Nothing essential for an agent to decide whether to invoke it is missing.

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?

The schema only describes 'query' as a natural-language question. The description adds substantial semantics: prefer natural language over exact identifiers, example question, what output styles can be requested, and appropriate question types. This goes well beyond the schema.

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 names a specific verb ('query'), resource ('codebase'), and a set of concrete use cases (entry points, module responsibilities, call chains, narrowing search scope). It explicitly distinguishes itself from pce_impact, so an agent can tell them apart.

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?

Contains explicit when-to-use and when-not-to-use guidance: use first when target location is unclear; avoid when exact file/identifier is known; switch to pce_impact for change-impact analysis. It even warns against manually traversing directories before trying this tool.

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