Skip to main content
Glama
raultov

knot

by raultov
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Rust
Hybrid

List indexed repositories

list_repositories
Read-onlyIdempotent

List all indexed repositories with optional name filtering to find codebases, showing language, build system, and file/entity counts.

Instructions

Read-only listing of all indexed repositories with optional name filtering. Shows repository metadata including entity count, file count, build system, and primary language. Answers 'what codebases have I indexed?' and 'which repositories match this name?'.

Usage: Use this tool FIRST to discover available codebases before searching or exploring. Once you know the repository name, switch to 'search_hybrid_context' for semantic search, 'find_callers' for reverse dependency lookup, 'explore_file' for file anatomy, or 'list_repo_dependencies' for cross-repo dependency graphs. Do NOT use this tool to search for code entities — use 'search_hybrid_context' instead.

Behaviour & Return: Read-only query with no side effects. Returns a Markdown table with columns: REPO, BUILD SYSTEM, LANGUAGE, FILES, ENTITIES. When no repositories match the filter, returns 'No repositories found.'

Parameter guidance: 'filter' is optional. When provided, only repositories whose name contains the filter string are returned (case-insensitive substring match). Omit to list all indexed repositories.

Supports all languages and build systems indexed by knot.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
filterNoOptional filter to narrow down repositories by name (case-insensitive substring match). When provided, only repositories whose name contains this string are returned. Examples: 'auth' matches 'auth-service' and 'Auth-Lib', 'api' matches 'my-api'. Omit to list all indexed repositories.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv1.9.4
    • changedInput schema / properties / filter / type
      Previous value: -"string"New value: +[
+  "string",
+  "null"
+]
  2. Addedv1.4.11

TDQS

A4.4/5.0
Behavior4/5

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so the safety profile is covered. The description adds genuinely new context: the return is a Markdown table with named columns, and the no-match case returns 'No repositories found.' That extra disclosure is valuable since there is no output schema, though permission/indexing prerequisites are not addressed.

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 purpose, then clearly sectioned into Usage, Behaviour & Return, and Parameter guidance. Slightly longer than necessary because the filter semantics and read-only nature repeat structured fields, but every section is scannable and earns its place.

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 supplies the return shape and empty-result behavior; with four sibling tools, it routes the agent to the correct alternative; with one fully-documented param, nothing else is needed. Complete for a low-complexity read tool.

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?

Schema description coverage is 100% and the single 'filter' param is fully documented in the schema (substring, case-insensitive, examples, optional). The description restates the same semantics rather than adding new meaning, so the baseline 3 is appropriate.

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+resource ('Read-only listing of all indexed repositories') plus the metadata surfaced and the questions it answers. An agent can distinguish it from search_hybrid_context, find_callers, explore_file, and list_repo_dependencies without opening any schema.

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?

Explicitly says to use this tool FIRST to discover codebases, names the exact sibling to switch to for each follow-up intent, and includes an explicit 'Do NOT use this tool to search for code entities' exclusion. Full when/when-not/alternatives coverage.

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