Which integrations are available for this server?

Enables settlement of music license payments on the Solana blockchain through a facilitator adapter that handles partially-signed transactions and durable nonces.

How do I use rights-mcp?

1. Click on "Install Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@rights-mcp search for calm lofi music" That's it! The server will respond to your query, and you can continue using it as needed. Here is a step-by-step guide with screenshots.

rights-mcp

by yksanjo

Overview Schema Related Servers Score Discussions

JavaScript

Hybrid

rights-mcp

The rights layer for the agent economy. An MCP server that lets an AI agent search, license, and pay for rights-clean music per use — and walk away with a verifiable license certificate proving it's allowed to use the track.

Built on x402 for payment and the fair-exchange escrow pattern from x402-pact: the agent's money only moves once the licensed asset and a signed certificate are bound to the payment. Zero dependencies, no SDK, no LLM in the loop — it runs anywhere Node runs and behaves identically whether or not any AI service is reachable.

Why this exists

An agent generating a video, ad, or stream doesn't need "a track." It needs a track it is allowed to use, with a paper trail proving it. That paper trail is only worth anything if whoever issues it actually controls the rights. That's the moat: the catalog adapter is the one piece a generic tool can't fake — it's where a real rights holder (e.g. a music catalog like Soundraw) plugs in.

Everything else here — pricing, escrow, certificates, the MCP wire protocol — is plumbing, and it's all built and tested.

Related MCP server: cc0company MCP

The loop

search_tracks ──▶ quote_license ──▶ license_track ──▶ verify_license
   (previews)       (price + x402     (pay → settle      (offline proof
                     requirements)     ONLY on delivery)   of rights)

npm run demo
# 1. search → picked "Low Tide" (trk_lowtide), creator price $0.162
# 2. quote  → q_7ab4..., $0.162 for creator usage
# 3. pay+settle → license lic_498f..., tx sim-settle:3a6b...
#    split: rights-holder $0.1377, platform $0.0243
# 4. verify → VALID certificate

MCP tools

Tool	What it does
`search_tracks`	Query the catalog by mood/genre/bpm/text. Returns previews + per-usage price estimates. No licensed asset.
`quote_license`	Price a track for a usage tier (`personal`/`creator`/`commercial`/`broadcast`); returns x402 `paymentRequirements` + a `quoteId`.
`license_track`	Pay a quote. Funds settle only after the asset + a signed certificate are bound to the payment (fair exchange). Returns the deliverable + certificate.
`verify_license`	Verify a certificate offline: validly signed by the rights issuer, with its terms.
`catalog_stats`	Issuer key, network, take rate, licenses issued, balances.

Run it as an MCP server

npm start          # stdio JSON-RPC, ready for any MCP client

Claude Desktop / Claude Code mcpServers entry:

{
  "mcpServers": {
    "rights": { "command": "node", "args": ["/abs/path/to/rights-mcp/src/server.js"] }
  }
}

Or drive it with no client (the "no LLM" path)

rights search "calm lofi"
rights quote trk_lowtide creator
rights license <quoteId>
rights verify <certificate>
rights stats

Economics

license_track settles the price and splits it on the certificate: rights holder gets their share, the platform keeps takeRateBps (default 15%). The split is signed into every license, so it's auditable, not a trust-me number. Set with RIGHTS_TAKE_BPS.

Configuration

Env	Default	Meaning
`RIGHTS_NETWORK`	`sim`	`sim` = no chain, auto-pays a funded demo wallet. A real network (e.g. `solana-mainnet`) requires a signed x402 payment.
`RIGHTS_TAKE_BPS`	`1500`	Platform cut in basis points.
`RIGHTS_PAYTO`	`soundraw-payout`	Rights-holder payout address.
`SOUNDRAW_API_KEY`	—	When set, swaps the sample catalog for the real Soundraw rights catalog.

What's real vs. stubbed (honest seams)

This is a working spine with two deliberate, clearly-labelled seams where production drops in:

Catalog — ships with an 8-track sample catalog so it runs with no credentials. SoundrawCatalog is the drop-in for the real rights API (same interface; the rest of the server is unchanged). Sample deliverables are labelled placeholders, not real licensed audio.
Settlement — SimBank proves the full escrow→split loop with no chain. A Solana facilitator adapter (settle a partially-signed tx / durable nonce) drops in behind the same calls. Real on-chain settlement is not yet wired.

Everything else — escrow/fair-exchange semantics, Ed25519 certificate signing & verification, double-spend / expiry / underpayment rejection, the MCP protocol — is real and covered by 17 no-mock tests (npm test), including a full roundtrip against the actual server over stdio.

License

MIT

Available Tools

5 tools

catalog_statsB

Operational stats: issuer key, network, take rate, licenses issued, balances.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

B3.1/5.0

Behavior2/5

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

No annotations are provided, so the description carries full burden. It mentions returning specific fields but does not disclose any behavioral traits (e.g., read-only nature, rate limits, or authentication requirements).

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?

The description is a single concise sentence. While efficient, it could be improved by starting with a clear verb (e.g., 'Returns operational stats...') for better structure.

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

Completeness3/5

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

With no output schema and no annotations, the description should provide more context about the returned data structure. Listing fields is helpful, but it is minimal and does not explain whether it's a single object or array, or any other details.

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 has zero parameters and schema coverage is 100%, so the description does not need to add parameter details. Baseline score of 4 applies.

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

Purpose4/5

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

The description clearly identifies the tool as providing operational stats and lists key fields, making its purpose understandable. However, it lacks an explicit action verb like 'get' or 'retrieve', which slightly reduces clarity.

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?

No guidance on when to use this tool versus alternatives. While sibling tools have different purposes, the description does not help the agent decide when this stats tool is appropriate.

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

license_trackA

Complete a license by paying its quote. Pass the quoteId and, on a real network, a signed x402 payment. Funds settle ONLY after the licensed asset and a signed license certificate are bound to the payment (fair exchange). Returns the deliverable asset and a verifiable certificate.

ParametersJSON Schema

Name	Required	Description	Default
`quoteId`	Yes
`payment`	No	signed x402 payment payload (omit on sim network to auto-pay)

TDQS

A4.6/5.0

Behavior5/5

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

Discloses key behavior: funds settle only after fair exchange (asset + certificate bound to payment). Returns deliverable and certificate. No annotations provided, so description carries full burden and meets it well.

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?

Three sentences, front-loaded with core purpose, then details. No redundancy or unnecessary words. Efficient and clear.

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?

Describes return values (asset and certificate) despite no output schema. Lacks discussion of error conditions or prerequisites (e.g., existing valid quote). Given sibling tools, fits workflow well but could be slightly more comprehensive.

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 50% (payment described, quoteId not). Description adds context for payment (real vs sim network) and repeats schema info. Provides meaningful addition but could elaborate on quoteId's purpose or format.

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?

Description clearly states it completes a license by paying a quote, with specific verb 'complete' and resource 'license'. It distinguishes from siblings like 'quote_license' which generates quotes, by specifying it finalizes payment and returns asset and certificate.

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?

Provides concrete guidance on passing quoteId and payment, with distinction between real and sim networks (omit payment on sim). Does not explicitly exclude alternatives but context makes it clear this is the final step after quoting.

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

quote_licenseA

Get a price quote and x402 payment requirements to license a specific track for a given usage. Returns a quoteId to pass to license_track.

ParametersJSON Schema

Name	Required	Description	Default
`trackId`	Yes
`usage`	No	personal \| creator \| commercial \| broadcast

TDQS

A4/5.0

Behavior3/5

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

No annotations are provided; the description states it 'gets' a quote, suggesting a read-only operation, but does not explicitly disclose behavioral traits such as side effects, permissions, or rate limits. It is adequate but could be more transparent.

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?

Two concise sentences that immediately state the purpose and the key output. No wasted words.

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?

The description covers the tool's purpose, output (quoteId), and relation to sibling tool 'license_track'. With no output schema and no annotations, it provides sufficient context for an agent to understand usage, though some details like response format are missing.

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?

The input schema has 50% description coverage (only 'usage' has a description). The tool description adds context by noting 'for a given usage', but does not provide additional specifics about 'trackId' format or constraints. It partially compensates for the schema gap.

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 description explicitly states 'Get a price quote and x402 payment requirements to license a specific track for a given usage', providing a specific verb and resource. It distinguishes itself from sibling tools like 'license_track' by noting that it returns a quoteId to pass to that tool.

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?

The description implies usage before 'license_track' by stating it returns a quoteId to pass to that tool. It does not explicitly state when not to use it or list alternatives, but the context of siblings makes the purpose clear.

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

search_tracksA

Search the rights catalog for music an agent is allowed to license. Returns candidate tracks with metadata and estimated per-usage price. Returns previews only — no licensed asset until license_track is paid.

ParametersJSON Schema

Name	Required	Description
`text`	No	free-text query (mood words, instruments, use)
`mood`	No	uplifting \| energetic \| tense \| calm
`genre`	No
`bpm`	No
`maxDurationSec`	No
`limit`	No	max results (1-25, default 5)

TDQS

A4/5.0

Behavior4/5

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

With no annotations, the description carries the full burden. It discloses that the tool returns previews (not licensed assets) and includes metadata and estimated price. It implies read-only behavior. Could mention more about real-time or caching, but sufficient for a search tool.

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?

Two sentences, front-loaded with purpose and key behavioral constraint. Every word adds value, no fluff.

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

Completeness3/5

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

Given 6 parameters, no output schema, and no annotations, the description is adequate but incomplete. It covers purpose and preview behavior but lacks details on parameter usage, return structure, and query complexity guidance.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 50% (3 of 6 parameters have descriptions). The tool description adds no extra parameter information beyond hinting at 'mood words, instruments, use' for the text parameter. This does not compensate for the gaps in schema descriptions.

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 description clearly states the tool's action ('Search') and resource ('rights catalog for music an agent is allowed to license'). It differentiates from siblings by specifying it returns candidate tracks, not stats or license actions.

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?

The description explicitly states that results are previews only and that a paid license is needed via 'license_track', implying when to use the tool (search) and when not (for licensed assets). However, it lacks explicit mention of alternatives or when to not use the tool.

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

verify_licenseA

Verify a license certificate offline. Returns whether it is validly signed by the rights issuer and the license terms it carries.

ParametersJSON Schema

Name	Required	Description	Default
`certificate`	Yes
`expectKid`	No	optional: pin the expected issuer key id

TDQS

A3.5/5.0

Behavior3/5

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

With no annotations, the description carries full burden. It discloses that the tool operates offline, checks signature, and returns license terms. However, it does not mention any side effects, error handling, or authentication requirements. It is adequate but lacks detail for a fully transparent description.

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?

Two sentences, no filler, directly stating purpose and output. Every word earns its place. Highly concise and well-structured.

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

Completeness3/5

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

Given no output schema, the description hints at the return value but does not specify its structure (e.g., boolean or object). Parameters are partially explained. For a simple tool with two params and no output schema, it is minimally viable but could be more complete by describing the return format and certificate format.

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 coverage is 50% (only expectKid has a description). The tool description adds context that the certificate is a 'license certificate' and that verification involves checking signature and terms, but it does not specify the certificate format or provide additional meaning beyond the schema. The compensation is partial.

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 description clearly states the tool verifies a license certificate offline, checking for valid signature and extracting terms. The verb 'verify' and resource 'license certificate' are specific, and the offline aspect distinguishes it from sibling tools like quote_license or license_track.

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?

No explicit guidance on when to use this tool versus alternatives. The description implies offline verification, but it does not mention exclusions or provide context for choosing this over siblings. No prerequisites or when-not-to-use are stated.

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

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.

5 tool updatesv0.1.0Jun 13, 2026
- First observedcatalog_stats
- First observedlicense_track
- First observedquote_license
- First observedsearch_tracks
- First observedverify_license

Install Server

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A3.8/5.0

Disambiguation5/5

Each tool has a clearly distinct purpose: catalog_stats for operational stats, search_tracks for browsing, quote_license for pricing, license_track for completing licenses, and verify_license for offline verification. No overlapping functionality.

Naming Consistency4/5

Most tools follow a verb_noun pattern (e.g., search_tracks, quote_license, verify_license). However, catalog_stats is a noun_noun form, creating a minor inconsistency. Overall, naming is clear and consistent with snake_case.

Tool Count5/5

With 5 tools, the server covers essential operations for a music rights licensing system—searching, quoting, licensing, verifying, and stats—without unnecessary bloat. The count feels well-scoped.

Completeness4/5

The core workflow (search→quote→license→verify) is fully supported. Missing operations like revoking licenses or listing owned licenses are minor gaps that agents can work around, but do not break the primary use case.

Maintenance

ActivityInactive

ResponsivenessSyncing

Resources

GitHub Repository

Need Help?

Related Servers

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

Tonr Music A
io.github.tanayyo1
Free, copyright-safe AI music library for video creators and AI agents.
Multimedia Processing Entertainment & Media AI & Machine Learning
2
moltdj A
io.github.bnovik0v
AI music and podcast platform for autonomous agents. SoundCloud for AI bots.
Autonomous Agents Audio Processing Entertainment & Media
3
agentic-commerce-catalog A
io.github.JasonColapietro
AI music, video, image, and voice tools callable by agents with USDC payments via x402 on Base.
AI & Machine Learning Blockchain Multimedia Processing
32
Achriom AOAuth
com.achriom.mcp
The media memory layer for AI agents and their humans. Your AI client gets 29 tools to search your collection, add items, update ratings, preview music, and find patterns across everything you've read, watched, and listened to.
Knowledge & Memory Entertainment & Media Search
2

Related MCP Servers

PixelVault
AI & Machine Learning Legal & Compliance Search
rsweeting1
A
license
A
quality
D
maintenance
AI asset compliance and licensing. Search pre-cleared assets matched to your brief. Usage agreement auto-generated at checkout. Works with Claude and any MCP-compatible agent.
Updated 4 months ago (2026-05-06 04:51 UTC)
3
70
MIT
cc0company MCP
Art & Culture AI & Machine Learning
cryptomfer
F
license
Not graded
quality
C
maintenance
Enables AI agents to query the largest CC0 database for provenance, license verification, and market data, and generate CC0 images, all via pay-per-call x402 micropayments.
Updated 2 months ago (2026-06-29 21:26 UTC)
-
BandSaaS MCP Server
Legal & Compliance Payments & Billing E-commerce & Retail
jyswee
A
license
Not graded
quality
B
maintenance
Enables musicians and their agents to manage AI licensing, register tracks by ISRC, issue/revoke licences, access compliance audit trails, and run their artist platform (merch, events, subscriptions, crowdfunding) through natural language with 46 tools.
Updated a month ago (2026-07-24 09:57 UTC)
11
1
-
AINSOF MCP Serverofficial
Entertainment & Media Audio Processing Multimedia Processing
AINSOF-Tech
A
license
Not graded
quality
A
maintenance
Enables AI assistants to search a curated production-music catalogue by brief or reference link, listen to full previews, and score videos with synced music, plus retrieve stems, versions, and cue sheets for licensing.
Updated 4 days ago (2026-09-02 17:22 UTC)
MIT

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/yksanjo/rights-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server

rights-mcp

Why this exists

The loop

MCP tools

Run it as an MCP server

Or drive it with no client (the "no LLM" path)

Economics

Configuration

What's real vs. stubbed (honest seams)

License

Available Tools

Tool Schema Changelog

Maintenance

Resources

Looking for Admin?

Related MCP Connectors

Related MCP Servers

AINSOF MCP Serverofficial

Latest Blog Posts

MCP directory API