list_topicsList the current crypto Topic landscape.
| Name | Required | Description | Default |
|---|---|---|---|
| ranking | No | trend for sustained attention | trend |
| projectId | No | Only Topics currently associated with this Project ID |
| Name | Required | Description | Default |
|---|---|---|---|
| data | Yes | ||
| meta | Yes |
Changes observed during successful MCP inspections. Dates show when Glama detected each change.
Input schema / properties / ranking / descriptionPrevious value: -"trend for sustained attention; emergence for the currently recalibrating board, which returns empty"New value: +"trend for sustained attention"Input schema / properties / ranking / enumPrevious value: -[
- "trend",
- "emergence"
-]New value: +[
+ "trend"
+]Output schema / properties / data / items / properties / emergenceRemoved value: -{
- "type": "number"
-}Input schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"Output schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"Output schema / properties / data / items / properties / report / anyOfPrevious value: -[
- {
- "additionalProperties": false,
- "properties": {
- "id": {
- "type": "string"
- },
- "publishedAt": {
- "type": "string"
- },
- "title": {
- "type": "string"
- }
- },
- "required": [
- "id",
- "title",
- "publishedAt"
- ],
- "type": "object"
- },
- {
- "type": "null"
- }
-]New value: +[
+ {
+ "additionalProperties": false,
+ "properties": {
+ "id": {
+ "type": "string"
+ },
+ "publishedAt": {
+ "type": "string"
+ },
+ "revisedAt": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ },
+ "title": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "id",
+ "title",
+ "publishedAt",
+ "revisedAt"
+ ],
+ "type": "object"
+ },
+ {
+ "type": "null"
+ }
+]Input schema / properties / ranking / descriptionPrevious value: -"trend for sustained attention; emergence for an experimental early-attention ranking signal"New value: +"trend for sustained attention; emergence for the currently recalibrating board, which returns empty"Input schema / properties / rankingAdded value: +{
+ "default": "trend",
+ "description": "trend for sustained attention; emergence for an experimental early-attention ranking signal",
+ "enum": [
+ "trend",
+ "emergence"
+ ],
+ "type": "string"
+}Output schema / properties / data / items / properties / emergenceAdded value: +{
+ "type": "number"
+}Output schema / properties / data / items / requiredPrevious value: -[
- "id",
- "rank",
- "name",
- "summary",
- "trend",
- "postCount",
- "authorCount",
- "lastSeenAt"
-]New value: +[
+ "id",
+ "rank",
+ "name",
+ "summary",
+ "postCount",
+ "authorCount",
+ "lastSeenAt"
+]Input schema / properties / projectId / descriptionPrevious value: -"Project id: serve the Topics associated with it"New value: +"Only Topics currently associated with this Project ID"Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the tool is clearly safe to call. The description adds the time dimension ('current') and the domain ('crypto'), but does not disclose if results are paginated, cached, or if there's any rate limiting. Since annotations cover the key safety info, the description gets a 3 for adding some context without contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise at just 6 words, with no wasted sentences. It quickly states the tool's action and domain. However, it could be slightly more specific about what 'Topic landscape' entails without sacrificing conciseness (e.g., 'List currently trending crypto topics').
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With only 2 parameters (0 required), a clear output schema, and read-only annotations, the tool is simple and the description is mostly adequate. The output schema likely handles return values, so no need to describe them. However, the description's vagueness about what 'Topic landscape' means leaves some ambiguity about the scope of results, especially given sibling tools like list_intel that could overlap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so both parameters are already documented in the schema with names, types, descriptions, and one enum. The description mentions 'current' but does not add any detail about the 'ranking' or 'projectId' parameters beyond what the schema provides. Baseline 3 is appropriate given full schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'List the current crypto Topic landscape' clearly identifies the tool's verb (List) and resource (Topic landscape), but it uses the vague phrase 'Topic landscape' which could mean different things. The title says 'trending topics', but the description does not reinforce that the list is specifically trending. Compared to siblings like list_intel and list_projects, this description does not explicitly differentiate itself.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies that the tool is used to see current crypto topics, but there is no guidance on when to use this tool versus siblings like list_intel or get_topic. No exclusions, prerequisites, or contextual alternatives are mentioned. The tool is non-destructive with no required params, so usage seems simple but lacks explicit when-to-use direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add one secure layer between your agents and this server.
Each tool targets a distinct entity or action: single vs. list (get vs. list), intel vs. project vs. topic vs. report vs. cluster vs. vocabulary vs. credential check. No two tools have overlapping purposes; the descriptions clearly differentiate them.
Uses a consistent pattern: get_ for singular retrieval, list_ for plural searches/listing. Only 'me' deviates, but it's a standard name for credential checks. The pattern is predictable and easy to follow.
12 tools cover a focused domain (crypto intelligence) without unnecessary bloat. Each tool earns its place: core entities (projects, topics, intel), plus series, reports, vocabulary, clusters, and auth check. The count feels well-scoped.
The server provides a complete read surface for its domain: listing, searching, getting details, historical series, reports, and filter metadata. No obvious gaps for consuming intelligence (CRUD not expected in a read-only API).