CWI Discovery Engine

Get Artist Profile

get_artist

Read-onlyIdempotent

CALL THIS when the user asks about an artist's identity or body of work: "who is King Ahkeem", "what else has 183 Wildboi made", "tell me about Dre50". Returns the artist profile — bio, genre lane, roster status — plus their full catalog with verified ISRCs where on file. Use get_track when the user asks about one specific song.

Input Schema

Name	Required	Description	Default
`name`	Yes	Artist name, e.g. "That Boy Hi Hat".

Output Schema

Name	Required	Description
`artist`	Yes
`tracks`	Yes
`_session`	No	Chain session: pass _session.session_token back in the next call to continue the chain.
`try_next`	No	Suggested follow-up calls, each a pre-compiled {tool, arguments, purpose} payload.
`track_count`	Yes
`related_nodes`	No	Up to 8 connected knowledge-graph node IDs.

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedOct 15, 2026

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "additionalProperties": true,
+  "description": "get_artist response: artist profile, catalog list, related graph nodes.",
+  "properties": {
+    "_session": {
+      "additionalProperties": false,
+      "description": "Chain session: pass _session.session_token back in the next call to continue the chain.",
+      "properties": {
+        "session_token": {
+          "description": "Hex session token; echo it as params._session.session_token to continue.",
+          "type": "string"
+        },
+        "step": {
+          "description": "Hop number in this chain (1 = chain start).",
+          "type": "integer"
+        }
+      },
+      "required": [
+        "session_token",
+        "step"
+      ],
+      "type": "object"
+    },
+    "artist": {
+      "type": "string"
+    },
+    "related_nodes": {
+      "description": "Up to 8 connected knowledge-graph node IDs.",
+      "items": {
+        "type": "string"
+      },
+      "type": "array"
+    },
+    "track_count": {
+      "type": "integer"
+    },
+    "tracks": {
+      "items": {
+        "additionalProperties": true,
+        "properties": {
+          "spotify_url": {
+            "type": "string"
+          },
+          "title": {
+            "type": "string"
+          }
+        },
+        "type": "object"
+      },
+      "type": "array"
+    },
+    "try_next": {
+      "description": "Suggested follow-up calls, each a pre-compiled {tool, arguments, purpose} payload.",
+      "items": {
+        "additionalProperties": false,
+        "description": "Pre-compiled next call: copy `arguments` straight into the next tools/call.",
+        "properties": {
+          "arguments": {
+            "additionalProperties": true,
+            "description": "Ready-to-use arguments, pre-populated from the current response.",
+            "type": "object"
+          },
+          "purpose": {
+            "description": "Why this call is the natural next step.",
+            "type": "string"
+          },
+          "tool": {
+            "description": "Tool to call next.",
+            "type": "string"
+          }
+        },
+        "required": [
+          "tool",
+          "arguments"
+        ],
+        "type": "object"
+      },
+      "type": "array"
+    }
+  },
+  "required": [
+    "artist",
+    "track_count",
+    "tracks"
+  ],
+  "type": "object"
+}

First observedOct 5, 2026

TDQS

A4.4/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, non-destructive), so the bar is lower. The description still adds real behavioral context: the response spans both profile metadata and the full catalog, and ISRCs are only included 'where on file', which sets expectations about data completeness. It stops short of noting breadth limits or pagination for a potentially large catalog.

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

Conciseness5/5

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

Front-loaded with the trigger before any payload detail, and every sentence does work: when to call, sample queries, what comes back, and which sibling to prefer instead. No filler or restatement of the title.

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?

An output schema exists, so return-value documentation is not needed, and the description still previews the response shape. For a tool that returns a 'full catalog', the absence of any note about result size, truncation, or pagination is a minor but real gap.

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% for the single 'name' parameter, so the schema already documents the input. The description's quoted artist examples illustrate query phrasing but add no matching-format or disambiguation guidance beyond what the schema provides, so the baseline 3 applies.

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+resource (fetch artist profile) and enumerates the payload: bio, genre lane, roster status, plus full catalog with verified ISRCs. It explicitly distinguishes itself from the nearest sibling, get_track, without requiring the agent to open either schema.

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

Usage Guidelines5/5

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

Gives an explicit trigger ('when the user asks about an artist's identity or body of work') reinforced with three concrete example utterances, and names the alternative (get_track) with the condition that selects it ('one specific song'). When-to-use, when-not, and the alternative are all present.

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

All CWI Discovery Engine tools Inspect

Try in Browser

Context All Your Agents Can ShareAgents share what they learn, hand off work, and hold it when you switch models. Start with 5 GB free.fulcradynamics.comAd

Glama MCP Gateway

Add one secure layer between your agents and this server.