Skip to main content
Glama

List sources

list_sources
Read-onlyIdempotent

Retrieve configured documentation sources with IDs, names, types, document/passage counts, and last sync status; use source IDs to narrow searches. Read-only; manage sources via CLI.

Instructions

Lists the configured documentation sources: id, name, type, document and passage counts, and the last sync status. Use the ids to narrow search with source_ids. Sources are added and synced only from the citepath CLI, not through MCP. Read-only.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A4.7/5.0
Behavior4/5

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint=false, so 'Read-only' is partly redundant. However, the description adds genuinely new behavioral context: sources can only be created/synced via the CLI, which no annotation conveys.

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?

Three short sentences with no filler. The purpose and returned fields are front-loaded, followed by the downstream usage hint and the CLI-only constraint.

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 available, the description compensates by enumerating the returned fields (id, name, type, counts, sync status). For a zero-parameter, read-only list tool this is fully sufficient.

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 tool takes zero parameters, so per the rubric the baseline is 4. The mention of source_ids belongs to the sibling search tool, not to this schema, so no additional parameter semantics are needed here.

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 (Lists) and resource (configured documentation sources), and enumerates the returned fields: id, name, type, document/passage counts, and last sync status. An agent can distinguish this from search and get_passage without opening a 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 tells the agent how to use the result ('Use the ids to narrow search with source_ids') and states an exclusion ('Sources are added and synced only from the citepath CLI, not through MCP'), preventing futile attempts to mutate sources through MCP.

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