Skip to main content
Glama
Rootly MCP server

Rootly MCP server

Official
by rootlyhq

List Catalog Properties

list_catalog_properties
Read-only

Fetches all properties for a specified catalog ID. Use to inspect catalog metadata via the Rootly API.

Instructions

List Catalog Properties - returns catalog_properties type

Input Schema

NameRequiredDescriptionDefault
catalog_idYesRequired. ID of the catalog (fills `{catalog_id}` in /v1/catalogs/{catalog_id}/properties).

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv2.4.0

TDQS

C2/5.0
Behavior2/5

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

Annotations already declare readOnlyHint=true, openWorldHint=true, and destructiveHint=false, so the safety profile is covered. The description adds only the vague phrase "returns catalog_properties type," with no detail on pagination, filtering scope, or whether the list is bounded by the catalog.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness2/5

Is the description appropriately sized, front-loaded, and free of redundancy?

It is short, but the length comes from under-specification rather than efficiency. The second clause duplicates information implied by the name and provides no actionable detail.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/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 should explain what is returned; "catalog_properties type" is opaque and gives no field or shape information. For a simple one-parameter read this is not catastrophic, but the definition is barely more than a label.

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?

The single parameter catalog_id has 100% schema description coverage, including the URL path mapping, so the schema carries the full burden. The description adds nothing beyond what the schema already states, which is the baseline-3 case.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose2/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description restates the tool name and title almost verbatim ("List Catalog Properties") without adding a verb-and-resource explanation. The trailing "returns catalog_properties type" hints at the return shape but does not say what a catalog property is or how it differs from the sibling list_catalog_entity_properties or list_catalog_properties variants.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines1/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

There is no guidance on when to call this versus alternatives such as list_catalog_entity_properties, get_catalog_property, or get_catalog. An agent must infer everything from the name alone.

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