Skip to main content
Glama

get_tool_catalog

Retrieve metadata for all registered MCP tools to access full documentation and parameter summaries; use when you need a wrapped catalog for tool discovery, not standard MCP tools/list.

Instructions

Get metadata for all registered MCP tools.

Use when: you need the wrapped catalog with full documentation and parameter summaries. Do not use when: your client only needs standard MCP tools/list discovery or a business result. Requires: no inputs; this call discovers tools and does not perform observing analysis. Follow-up: choose a tool from its use/do-not-use guidance; plan_stargazing_session is the primary entry for complete observing decisions.

Returns: Dict with keys "data", "_meta". "data.tools" contains tool metadata objects.

Input Schema

NameRequiredDescriptionDefault

No arguments

Output Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv0.3.0

TDQS

A4.6/5.0
Behavior4/5

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

With no annotations, the description carries the behavioral burden. It discloses that the tool takes no inputs, discovers tools rather than performing observing analysis, and returns a dict with 'data' and '_meta' keys. It does not mention permissions or rate limits, but for a no-input discovery tool the key behavioral traits are covered.

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?

The description is structured and front-loaded, with clear sections for usage and returns. It is slightly verbose but every sentence supports correct tool selection or invocation.

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?

Given this is a zero-parameter discovery tool with an output schema, the description is complete: it explains inputs, usage boundaries, follow-up, and return structure. An agent should be able to call it correctly without additional context.

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 has zero parameters, so parameter semantics are inherently simple. The description appropriately states 'no inputs' rather than inventing parameter details.

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?

The description states a specific verb and resource: 'Get metadata for all registered MCP tools.' It also distinguishes this tool from standard MCP tools/list discovery, making the purpose clear relative to sibling discovery behavior.

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?

It explicitly provides when to use, when not to use, required inputs, and a follow-up path. The guidance distinguishes this catalog tool from business/analysis tools and from standard client-side discovery.

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