Skip to main content
Glama
zix-chen
by zix-chen

Find target rules, skills and recipes

workspace_guide
Read-onlyIdempotent

Locate applicable repository instructions and skill metadata for a target path, then read the full selected files before acting; no execution or permission is granted.

Instructions

Find applicable repository instructions and skill metadata for a target path. Read the selected full files before acting; no execution or permission grant.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
pathNoExisting workspace-relative target repository, directory or file..

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
okYes
errorNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.1

TDQS

A3.8/5.0
Behavior4/5

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

Annotations already cover read-only, idempotent, non-destructive, closed-world semantics, so the bar is low. The description still adds real value: it warns that the tool grants no execution or permission, and that returned metadata must be followed by reading the full files before acting — behavior not derivable from the annotations.

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 tight sentences, zero filler, with the core action stated first and the caveat ('no execution or permission grant') front-loaded in the same breath. Every clause earns its place.

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?

An output schema exists, so return-value explanation is not required. The description covers what the tool produces (instructions/skill metadata), the required follow-up action, and its safety posture; only the relative ranking against sibling discovery tools (search_text, list_dir) is left unaddressed.

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?

Single optional 'path' parameter with 100% schema description coverage, so the schema already documents purpose, type, and default. The description's 'for a target path' merely restates it without adding format or path-resolution detail; baseline 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb ('Find') and a specific resource ('applicable repository instructions and skill metadata') scoped to a target path. It is distinguishable from read_file/list_dir/search_text by being about discovering rules/skills metadata rather than raw content, though it never names those siblings as alternatives.

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

Usage Guidelines3/5

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

'Read the selected full files before acting' implies a two-step workflow (this tool locates, another read retrieves content), which is useful. However, there is no explicit statement of when to prefer this over search_text or list_dir, or what conditions make it inapplicable.

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