Dynamoi

Check Distribution Application

dynamoi_get_distribution_application

Read-only

Use this when the user asks whether an artist qualifies for Dynamoi music distribution, wants the five application requirements, or wants the status of an existing distribution application. It checks Spotify connection, at least 1,000 Spotify followers, at least 10,000 verified Soundcharts monthly listeners, connected Facebook Page plus Instagram professional identity, and a connected YouTube channel. Meeting all five requirements permits an application but never guarantees approval. When the connection tools are available, use purpose=distribution_identity for missing Meta or YouTube identity; otherwise tell the user: 'You can do this in the Dynamoi dashboard at https://dynamoi.com/dashboard.' Identity connections do not require advertising billing.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`artistId`	Yes

Output Schema

TableJSON Schema

Name	Required	Description	Default
`code`	No
`data`	No
`kind`	No
`field`	No
`status`	Yes
`draftId`	No
`message`	No
`retryable`	No
`nextAction`	No
`failureStage`	No
`prerequisite`	No
`screeningResult`	No
`retryAfterSeconds`	No

Schema Changelog

Changes observed during successful MCP inspections.

Changed3 schema fields changedSep 24, 2026

addedOutput schema / properties / draftId

Added value: +{
+  "format": "uuid",
+  "pattern": "^([0-9a-fA-F]{8}-[0-9a-fA-F]{4}-[1-8][0-9a-fA-F]{3}-[89abAB][0-9a-fA-F]{3}-[0-9a-fA-F]{12}|00000000-0000-0000-0000-000000000000|ffffffff-ffff-ffff-ffff-ffffffffffff)$",
+  "type": "string"
+}

addedOutput schema / properties / failureStage

Added value: +{
+  "maxLength": 120,
+  "minLength": 1,
+  "type": "string"
+}

addedOutput schema / properties / screeningResult

Added value: +{
+  "maxLength": 120,
+  "minLength": 1,
+  "type": "string"
+}

Changed2 schema fields changedSep 23, 2026

removedInput schema / $schema

Removed value: -"http://json-schema.org/draft-07/schema#"

removedOutput schema / $schema

Removed value: -"http://json-schema.org/draft-07/schema#"

Changed2 schema fields changedSep 20, 2026

addedInput schema / $schema

Added value: +"http://json-schema.org/draft-07/schema#"

addedOutput schema / $schema

Added value: +"http://json-schema.org/draft-07/schema#"

Changed6 schema fields changedSep 10, 2026

addedOutput schema / properties / code

Added value: +{
+  "enum": [
+    "ACCOUNT_READ_ONLY",
+    "INVALID_SPOTIFY_SOURCE",
+    "CAPABILITY_REQUIRED",
+    "INSUFFICIENT_SCOPE",
+    "STATE_CONFLICT",
+    "QUOTE_CHANGED",
+    "RATE_LIMITED",
+    "OUTPUT_INVALID",
+    "UNKNOWN_EFFECT"
+  ],
+  "type": "string"
+}

addedOutput schema / properties / field

Added value: +{
+  "maxLength": 120,
+  "minLength": 1,
+  "type": "string"
+}

addedOutput schema / properties / nextAction

Added value: +{
+  "additionalProperties": false,
+  "properties": {
+    "field": {
+      "maxLength": 120,
+      "minLength": 1,
+      "type": "string"
+    },
+    "kind": {
+      "enum": [
+        "provide_input",
+        "read_status",
+        "reconnect",
+        "handoff"
+      ],
+      "type": "string"
+    },
+    "reason": {
+      "maxLength": 240,
+      "minLength": 1,
+      "type": "string"
+    }
+  },
+  "required": [
+    "kind"
+  ],
+  "type": "object"
+}

addedOutput schema / properties / prerequisite

Added value: +{
+  "maxLength": 240,
+  "minLength": 1,
+  "type": "string"
+}

addedOutput schema / properties / retryAfterSeconds

Added value: +{
+  "maximum": 86400,
+  "minimum": 0,
+  "type": "integer"
+}

addedOutput schema / properties / retryable
```
Added value: +{
+  "type": "boolean"
+}
```

AddedAug 25, 2026

TDQS

A4.9/5.0

Behavior5/5

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

Annotations already mark read-only and non-destructive; the description adds meaningful behavioral context: meeting all five requirements only permits an application, never guarantees approval, and identity connections don't require advertising billing. It also prescribes the fallback for missing connections.

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?

The description is front-loaded with use conditions, then lists criteria in a compact enumeration, then gives fallback instructions. Every sentence carries either selection guidance or behavioral caveats; nothing is redundant.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The tool has a simple one-parameter schema and an output schema, so the description doesn't need return-value details. It covers triggers, criteria, approval caveat, missing-connection handling, and billing nuance, making it complete for invocation.

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?

There is only one required parameter, artistId, and the description consistently frames the operation as evaluating 'an artist', making the parameter's role clear without naming it. It doesn't add format details, but the schema's format/pattern fully covers validation, and no enum/choice ambiguity exists.

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?

The opening sentence names a specific action ('check whether an artist qualifies'), the exact resource (Dynamoi music distribution application), and three triggering user intents. It lists the five concrete criteria, which differentiates it from sibling apply_for_distribution and other status tools.

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?

It explicitly says 'Use this when...' and enumerates the three request types. It also tells the agent when to delegate missing identity connections to purpose=distribution_identity and gives the exact fallback message, so the agent knows when not to use this tool alone.

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

All Dynamoi tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.