Skip to main content
Glama
Sign In
Task Handoff Verifier

Task Handoff Verifier

by Harmantaj
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

find_repos

Read-only

Locate local Git repositories by project name or path fragment, sorted by recent activity. Use this to resolve named projects before verifying an AI agent's work.

Instructions

Find git repositories on this computer (inside the allowed directories, or the home folder), most recently active first. Use it when the user names a project ('my shop app') instead of giving a path.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "find_repos"
  }
}

Input Schema

NameRequiredDescriptionDefault
limitNo
queryNoCase-insensitive part of the repo path, e.g. 'shop'. Empty lists all.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.3.0

TDQS

A4/5.0
Behavior4/5

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

Annotations only declare readOnlyHint and a title, so the description carries the rest: it discloses the search scope (allowed dirs or home folder) and the result ordering (most recently active first). It stops short of stating anything about pagination/limit behavior or how deep the filesystem is walked.

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 sentences, zero filler, with the scope/ordering fact front-loaded and the usage cue second. 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?

No output schema exists, so the description must convey enough on its own; combined with the schema it covers what the tool does, where it searches, and how results are ordered. Minor gaps remain around result shape and whether the limit is honored across directories, but nothing essential to invocation is missing.

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?

At 50% schema coverage only 'query' is documented in the schema; 'limit' is undocumented. The description adds no parameter detail at all, but the undocumented param (an integer with default 20, max 50) is largely self-explanatory, so the baseline of 3 is appropriate rather than a penalty.

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 and resource ('Find git repositories') plus scope ('on this computer, inside the allowed directories or the home folder') and ordering ('most recently active first'). It doesn't need to differentiate from siblings, which are unrelated task tools, so it stops short of a 5 only in that it doesn't frame the result set (e.g. what a 'repo' entry contains).

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?

Gives an explicit trigger with a contrasting alternative: use it when the user names a project ('my shop app') rather than supplying a path. That is clear when-to-use guidance, but it names no sibling tool to route against and states no exclusions beyond the path case.

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