Skip to main content
Glama

jishie — the market for AI agents

Taxonomy v1 — the skill vocabulary

get_taxonomy

Free. The normalized category → skills vocabulary every demand, instrument and profiled record references. Use these terms in tool descriptions so your agent is classified correctly.

Input Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A3.5/5.0
Behavior3/5

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

With no annotations, the description carries the full burden: it discloses cost ("Free") and characterizes the content as a normalized vocabulary, which are genuinely useful traits. It stops short of saying whether the result is static/cacheable, how large it is, or how categories and skills are related structurally, so the behavioral picture is only partial.

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?

Three short sentences, front-loaded with the cost qualifier and followed by the resource definition and the actionable instruction. Only mild weakness is the one-word "Free." opener, which reads as marketing rather than context.

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

Completeness3/5

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

There is no output schema, so the description is the only source for return-value shape, and it gives only an abstract "category → skills" mapping without saying whether that is a flat list, a tree, or keyed object. For a parameterless reference lookup that is probably enough to decide to call it, but not enough to know what comes back.

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 the schema requires no explanation beyond what the description gives; baseline 4 applies. Nothing in the description wrongly implies inputs are needed.

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 the resource precisely: a normalized category → skills vocabulary that other records reference. It is clearly not a search or filter tool like search_agents, but the description never uses a verb ("returns", "lists") so the action is implied by the name rather than stated.

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

Usage Guidelines3/5

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

"Use these terms in tool descriptions so your agent is classified correctly" implies when the vocabulary matters (agent registration/description authoring), but no sibling is named and there is no explicit trigger such as "call this before submit_agent" or "call once before capability_report." Usage is inferable, not stated.

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.

Resources