Skip to main content
Glama

Stellara

Stellara Famous People

list_celebrities
Read-onlyIdempotent

Lists the famous people you can compare charts with in compare_charts (about 1000 most-followed real people on X, birth dates from Wikidata cross-checked with Grokipedia). Optional search query (name, handle or description such as 'singer'); returns up to 25, most followed first. Most are date-only.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
queryNoOptional search text, for example 'singer' or 'Taylor'.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.3/5.0
Behavior4/5

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

Annotations already cover the safety profile (readOnly, idempotent, closed-world), so the description's added value is the data provenance (most-followed people on X, birth dates from Wikidata cross-checked with Grokipedia), the 25-item cap, the most-followed-first ordering, and the date-only caveat. These are genuinely non-obvious traits that would otherwise surprise a caller.

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?

Purpose and integration point come first, then the parameter behavior and return characteristics. The trailing fragment 'Most are date-only.' is terse and slightly ambiguous, but overall the text is dense with information and nearly waste-free.

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?

With no output schema, the description carries the burden of describing results and does so: count cap, ordering, and the date-precision caveat. Provenance and the compare_charts link round it out; only the exact returned fields are left implicit.

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?

Schema coverage is 100% and the query param is already documented with an example. The description still adds meaning by enumerating accepted input kinds — name, handle, or description such as 'singer' — which the schema does not spell out, so it edges above the baseline 3.

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?

States a specific verb and resource ('Lists the famous people') and immediately ties it to its consumer, compare_charts, which no sibling tool claims. An agent can distinguish it from get_birth_chart or compare_charts without opening a schema.

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?

It establishes clear context — this is the lookup step feeding compare_charts — and explains the optional query. It does not state when not to use it or name an alternative discovery path, so it stops short of a full routing rule.

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.