Skip to main content
Glama

Gluecron

by com.gluecron
OverviewDiscussionsAdmin

gluecron_search_code

Read-only

Literal / regex code search (git grep, basic regex) across a repo at a ref. The dependable way to find code on this host — works on every repo, indexed or not. Optional scoping: path (a directory or file prefix, literal), glob (git pathspec glob such as src/**/*.ts, relative to path when both are given), ignore_case, and files_only (unique files with match counts instead of lines). Returns {owner, repo, ref, total, truncated, matches: [{file, line, text}]}, or with files_only {owner, repo, ref, total, totalMatches, truncated, files: [{file, count}]}. Omit ref for the default branch.

Input Schema

NameRequiredDescriptionDefault
refNoBranch / tag / sha (default: the repo's default branch)
globNoOnly search files matching this git pathspec glob (e.g. **/*.test.ts); relative to `path` when both are given
pathNoOnly search under this repo-relative directory or file (literal prefix, e.g. src/lib)
repoYes
limitNoMax matches, or max files with files_only (default 50, max 200)
ownerYes
queryYesPattern (git grep basic regex)
files_onlyNoReturn unique files with match counts instead of matching lines
ignore_caseNoCase-insensitive match (default false)

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed5 schema fields changed
    • addedInput schema / properties / files_only
      Added value: +{
+  "description": "Return unique files with match counts instead of matching lines",
+  "type": "boolean"
+}
    • addedInput schema / properties / glob
      Added value: +{
+  "description": "Only search files matching this git pathspec glob (e.g. **/*.test.ts); relative to `path` when both are given",
+  "type": "string"
+}
    • addedInput schema / properties / ignore_case
      Added value: +{
+  "description": "Case-insensitive match (default false)",
+  "type": "boolean"
+}
    • changedInput schema / properties / limit / description
      Previous value: -"Max matches (default 50, max 200)"New value: +"Max matches, or max files with files_only (default 50, max 200)"
    • addedInput schema / properties / path
      Added value: +{
+  "description": "Only search under this repo-relative directory or file (literal prefix, e.g. src/lib)",
+  "type": "string"
+}
  2. Added

TDQS

A4.4/5.0
Behavior4/5

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so safety is covered; the description adds genuine behavioral context on top — the exact return shapes for both normal and files_only modes, the presence of a `truncated` flag, and the default-branch behavior when ref is omitted. It stops short of noting rate limits or how truncation is triggered.

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, then scoping options, then return shape, then the ref default — a logical order. Dense but each clause carries information; the two return-shape snippets are slightly verbose but justified since no output schema exists.

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?

For a 9-parameter tool with no output schema, the description covers the essential gaps: it documents both return formats, the truncation field, scoping interactions, and the default-ref behavior. Nothing an agent needs to invoke it correctly is missing.

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 78% (baseline 3), and the description meaningfully exceeds it: it clarifies that `path` is a literal prefix, that `glob` is a git pathspec glob, and crucially that glob is relative to `path` when both are given, plus what `files_only` changes about the result. owner/repo are left unexplained but are self-evident.

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 ('Literal / regex code search (git grep, basic regex) across a repo at a ref') and differentiates itself from indexed alternatives by noting it 'works on every repo, indexed or not'. An agent can tell this apart from semantic_search/find_symbol without opening either schema.

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?

Provides a clear usage cue ('The dependable way to find code on this host') implying it is the fallback when indexed search isn't available, but it never names a specific alternative (e.g. semantic_search or find_symbol) or states an explicit when-not condition. Clear context, no exclusions.

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

All Gluecron toolsInspect
Try in Browser
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources