Skip to main content
Glama

List Taxonomy Mappings

list_taxonomy_mappings
Read-onlyIdempotent

Retrieve available taxonomy mapping names and their source and destination versions so you can choose the correct mapping before resolving taxonomy IDs.

Instructions

Discover mapping names and source/destination taxonomy versions; do this before mapping IDs.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "list_taxonomy_mappings"
  }
}

Input Schema

NameRequiredDescriptionDefault

No arguments

Output Schema

NameRequiredDescriptionDefault
resultYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.4.1

TDQS

A3.9/5.0
Behavior3/5

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false and openWorldHint=true, so the safety profile is fully covered structurally. The description adds that the return includes mapping names and source/destination taxonomy versions, but says nothing about result volume, pagination, or how many versions typically exist. With annotations doing most of the work, this is a modest contribution.

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?

A single compact sentence split into two clauses: what you get first, then the sequencing instruction. No filler, no restatement of the title, and nothing that could be trimmed without losing meaning.

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

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

An output schema exists and annotations cover the safety profile, so the description only needs to convey purpose and ordering. It does both, and the zero-parameter surface leaves little else to explain; only a note on result size or typical content count is missing.

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 baseline there is nothing for the description to disambiguate. The description does not introduce confusion about inputs and correctly implies a no-argument enumeration.

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

Purpose4/5

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

States a specific verb ('Discover') and resource ('mapping names and source/destination taxonomy versions'). An agent can distinguish it from map_taxonomy_concepts because this one enumerates available mappings/versions rather than performing a mapping, though the description never names the sibling explicitly.

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?

Gives an explicit prerequisite: 'do this before mapping IDs,' which tells the agent this is a discovery step that precedes the actual mapping call. It lacks a stated exclusion (e.g., what to do if you already know the mapping name), but the sequencing guidance is clear and actionable.

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