Skip to main content
Glama
Sign In
esa MCP Server

esa MCP Server

Official
by esaio
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

Get categories for a specific path

esa_get_categories
Read-only

Retrieves category details and subcategories for a specified category path, optionally including posts or parent categories.

Instructions

Retrieves category information and subcategories for a specific category path, with optional posts and parent categories included

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "select": "<select>"
    },
    "name": "esa_get_categories"
  }
}

Input Schema

NameRequiredDescriptionDefault
pageNoPage number (starts from 1)
selectYesCategory path to retrieve
includeNoAdditional information to include
perPageNoNumber of items per page
teamNameNoTeam name (required). Use esa_get_teams first to see available teams.
descendantPostsNoInclude descendant posts (only effective with include=posts)

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv0.15.1
    • removedInput schema / additionalProperties
      Removed value: -false
  2. First observedv0.13.0

TDQS

B3.2/5.0
Behavior3/5

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

Annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=false, so the safety profile is covered. The description adds value by saying optional posts and parent categories can be attached to the response, which is useful return-shape context given there is no output schema. It stops short of describing pagination behavior or response structure.

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?

One compact sentence with no filler, and the core action plus scope is front-loaded. The trailing 'with optional posts and parent categories included' is slightly dense but still earns its place by previewing the include options.

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?

With no output schema, the description must carry more of the return-value burden, and 'category information' is vague about the shape (name, id, hierarchy depth). Pagination and the teamName prerequisite are also unaddressed, so a 6-parameter tool is only adequately described.

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?

Schema description coverage is 100%, so all six parameters are documented in the schema, which sets the baseline at 3. The description only echoes the 'include' concept ('optional posts and parent categories') and adds nothing about the 'select' path syntax, the paging interaction, or that teamName is effectively required despite the schema's empty default.

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?

The description names a specific verb (retrieves) and resource (category information and subcategories) scoped to a category path, which separates it from path-less siblings like esa_get_all_category_paths and esa_get_top_categories. It is clear but never names those siblings to disambiguate explicitly.

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

Usage Guidelines2/5

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

No when-to-use or when-not-to-use guidance is given, and none of the closely related siblings (esa_get_all_category_paths, esa_get_top_categories) are referenced. An agent must infer from the phrase 'specific category path' that this is the per-path variant.

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