Skip to main content
Glama

grove_blueprint_get

Read-only

Retrieve paginated blueprint items from a project's last scan—declared docs, actual code symbols, and test names—filterable by layer or substring; it does not rescan.

Instructions

Read a project's blueprint items, paginated: what docs declare (declared), what the code appears to contain (actual: modules and symbol names) and what tests appear to prove (tests: test names). Optionally filter by layer and by a case-insensitive substring of title, body or path. Reads Grove's stored result of the last scan; it does not rescan. Grove is local only: scans are read-only and nothing is sent to GitHub or any other service.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "project": "<project>"
    },
    "name": "grove_blueprint_get"
  }
}

Input Schema

NameRequiredDescriptionDefault
layerNo
limitNoPage size (default 50, max 200).
queryNoSubstring to look for in title, body or source path.
offsetNoNumber of items to skip.
projectYesProject name, or its numeric id.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A4.6/5.0
Behavior5/5

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

Beyond the read-only, non-destructive, closed-world annotations, it discloses the important snapshot behavior and potential staleness inherent in reading only the last stored scan. The local-only and no-external-transmission statements add privacy context, while "appears to contain" and "appear to prove" appropriately convey that code and test observations are inferential.

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?

Four focused sentences front-load the operation and resource, then cover layers, filtering, snapshot behavior, and privacy in a logical order. There is no filler, and each sentence contributes information useful for selection or invocation.

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 five-parameter read operation, the definition covers the essential invocation semantics and the crucial no-rescan behavior. Because there is no output schema, it could still be more complete by describing the returned item or pagination envelope and by briefly explaining the workflow for refreshing stale scan results.

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?

The description adds substantial meaning beyond the schema by defining all three layer enum values and clarifying that query matching is case-insensitive across title, body, or path. Pagination and the remaining parameters rely mostly on the already-strong schema, so the added parameter guidance is valuable but not exhaustive.

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 gives a specific verb and resource: reading a project's paginated blueprint items. It also explains the declared, actual, and tests layers and states that the tool reads stored scan results rather than rescanning, clearly distinguishing it from a scan operation or generic project read.

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 use context is clear: inspect or filter the blueprint produced by the last scan, with an explicit warning that this tool does not rescan. It would be stronger with guidance on what to use when fresh results are needed and whether running a scan first is a prerequisite.

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