sa-ecosystem-node

List categories

list_categories

Read-onlyIdempotent

Lists v0 ecosystem category IDs for Star Atlas-inspired data, clarifying that approved members remain unknown until a public roster exists. Read-only.

Instructions

The v0 ecosystem category ids. Approved members are unknown until a public roster exists. Read-only.

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_categories"
  }
}

Input Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

First observedv1.0.0Nov 4, 2026

TDQS

B3.1/5.0

Behavior3/5

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so "Read-only" merely restates structured data with no added value. The one genuinely new piece of information is the caveat that approved members are unknown until a public roster exists, which warns the agent that membership status cannot be derived from this response. The description does not state the return shape (bare ids vs. objects) or whether the list is static.

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

Conciseness3/5

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

The text is short and front-loads the resource, but the middle sentence about approved members is ambiguous (members of what?) and the closing "Read-only." duplicates the annotations rather than earning its place. Tightening to a single clause about returning v0 ecosystem category ids, with the roster caveat attached to it, would be clearer.

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?

For a zero-parameter, read-only lookup with no output schema, the definition covers the essentials: what concept it exposes (v0 ecosystem category ids) and the key limitation (approved membership unresolved without a public roster). Only the response structure is left implicit, which is a minor gap for a simple enumeration tool.

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 there is nothing for the description to disambiguate; baseline for a no-parameter tool applies. The schema is empty and fully described by definition, and the description adds no misleading parameter claims.

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

Purpose3/5

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

The description identifies the resource ("the v0 ecosystem category ids"), implying a listing, but it is a noun phrase rather than a verb+resource statement, and it never distinguishes this from siblings such as list_star_systems or list_listings. An agent can infer it returns category identifiers, but the purpose statement is vaguer than it needs to be.

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?

There is no guidance on when to call this tool, what task it supports, or which sibling to use instead. The sentence about approved members being unknown until a public roster exists hints at a data limitation but does not tell the agent when this tool is or isn't appropriate.

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