Skip to main content
Glama

meta-tools.list_group_tools

List live tools belonging to a single capability group.

Use group_id from meta-tools.list_groups (for example website-screenshots). Returns name and summary for each live tool in the group

Cost = 0 tokens.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
group_idYesGroup id to list tools for (for example website-screenshots).

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
toolsNoLive tool summaries in the requested group.
group_idNoRequested group id.

Schema Changelog

Changes observed during successful MCP inspections. Dates show when Glama detected each change.

  1. Changed3 schema fields changed
    • removedOutput schema / $defs / ListGroupToolsResponseToolsItem / properties / group_id
      Removed value: -{
      -  "anyOf": [
      -    {
      -      "type": "string"
      -    },
      -    {
      -      "type": "null"
      -    }
      -  ],
      -  "default": null,
      -  "description": "Capability group id.",
      -  "title": "Group Id"
      -}
    • removedOutput schema / $defs / ListGroupToolsResponseToolsItem / properties / mcp_tool_name
      Removed value: -{
      -  "anyOf": [
      -    {
      -      "type": "string"
      -    },
      -    {
      -      "type": "null"
      -    }
      -  ],
      -  "default": null,
      -  "description": "MCP tool name when the capability is exposed over MCP.",
      -  "title": "Mcp Tool Name"
      -}
    • addedOutput schema / $defs / ListGroupToolsResponseToolsItem / properties / name
      Added value: +{
      +  "anyOf": [
      +    {
      +      "type": "string"
      +    },
      +    {
      +      "type": "null"
      +    }
      +  ],
      +  "default": null,
      +  "description": "MCP tool name when the capability is exposed over MCP.",
      +  "title": "Name"
      +}
  2. Changed7 schema fields changed
    • removedOutput schema / $defs / ListGroupToolsResponseToolsItem / properties / capability_id
      Removed value: -{
      -  "anyOf": [
      -    {
      -      "type": "string"
      -    },
      -    {
      -      "type": "null"
      -    }
      -  ],
      -  "default": null,
      -  "description": "Capability id (for example website-screenshot).",
      -  "title": "Capability Id"
      -}
    • removedOutput schema / $defs / ListGroupToolsResponseToolsItem / properties / display_name
      Removed value: -{
      -  "anyOf": [
      -    {
      -      "type": "string"
      -    },
      -    {
      -      "type": "null"
      -    }
      -  ],
      -  "default": null,
      -  "description": "Human-readable capability name.",
      -  "title": "Display Name"
      -}
    • removedOutput schema / $defs / ListGroupToolsResponseToolsItem / properties / group_display_name
      Removed value: -{
      -  "anyOf": [
      -    {
      -      "type": "string"
      -    },
      -    {
      -      "type": "null"
      -    }
      -  ],
      -  "default": null,
      -  "description": "Human-readable group name.",
      -  "title": "Group Display Name"
      -}
    • removedOutput schema / $defs / ListGroupToolsResponseToolsItem / properties / rest_method
      Removed value: -{
      -  "anyOf": [
      -    {
      -      "type": "string"
      -    },
      -    {
      -      "type": "null"
      -    }
      -  ],
      -  "default": null,
      -  "description": "HTTP method for the REST endpoint.",
      -  "title": "Rest Method"
      -}
    • removedOutput schema / $defs / ListGroupToolsResponseToolsItem / properties / rest_path
      Removed value: -{
      -  "anyOf": [
      -    {
      -      "type": "string"
      -    },
      -    {
      -      "type": "null"
      -    }
      -  ],
      -  "default": null,
      -  "description": "REST path for the capability.",
      -  "title": "Rest Path"
      -}
    • removedOutput schema / $defs / ListGroupToolsResponseToolsItem / properties / status
      Removed value: -{
      -  "anyOf": [
      -    {
      -      "type": "string"
      -    },
      -    {
      -      "type": "null"
      -    }
      -  ],
      -  "default": null,
      -  "description": "Capability status (live, soon, or deprecated).",
      -  "title": "Status"
      -}
    • removedOutput schema / $defs / ListGroupToolsResponseToolsItem / properties / token_cost
      Removed value: -{
      -  "anyOf": [
      -    {
      -      "type": "integer"
      -    },
      -    {
      -      "type": "null"
      -    }
      -  ],
      -  "default": null,
      -  "description": "API tokens charged for one successful call.",
      -  "title": "Token Cost"
      -}
  3. First observed

TDQS

A4.5/5.0
Behavior4/5

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

With no annotations provided, the description carries the full burden. It discloses that the tool returns name and summary for each live tool, and mentions 'Cost = 0 tokens.' It also implies read-only behavior and dynamic availability ('live tools'). This is useful behavioral context, though it omits details like pagination or error handling.

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?

The description is three sentences, each earning its place: purpose, usage instruction, and output/cost. It is front-loaded with the primary function and contains no filler or repetition.

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 the tool's simplicity (one parameter, output schema present), the description is complete. It covers what the tool does, how to get the input, what the output contains, and the cost. No critical information is missing for effective use.

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 schema already covers the parameter with a description and example, so the baseline is 3. The description adds value by instructing to source group_id from meta-tools.list_groups, which is not in the schema. This extra provenance guidance enriches the parameter semantics.

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 clearly states the tool's function: 'List live tools belonging to a single capability group.' This specifies the verb (list), the resource (live tools), and the scope (single capability group), distinguishing it from sibling tools like list_groups and list_all.

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?

The description provides clear context by instructing to 'Use group_id from meta-tools.list_groups' with an example. This tells the agent how to obtain the parameter value. However, it does not explicitly contrast with alternatives like list_all or search, so it lacks explicit when-not-to-use guidance.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A4.1/5.0
Disambiguation5/5

Each tool has a distinct purpose, further clarified by group prefixes and clear descriptions. Within each group, tools perform different operations (e.g., domains.lookup vs. domains.whois vs. domains.rdap) with no ambiguity.

Naming Consistency5/5

All tools follow a consistent group.tool_name pattern using snake_case. The naming is predictable and uniformly applied across all groups.

Tool Count4/5

78 tools is high, but the server aggregates multiple distinct API domains (11 groups). Each group has a reasonable number of tools, typically under 10, with TikTok having 17. The count reflects breadth, not bloat.

Completeness5/5

Each domain's tool set covers the primary expected operations (e.g., search, details, reviews, metrics, user info). There are no obvious gaps for read-only analytical use; features like posting are likely out of scope.