withPICA Directory

Send a licensing enquiry

directory_send_licensing_enquiry

Destructive

Use when the user asks: 'ask the owner if I can license this', 'send a licensing enquiry for X', 'contact the rights holder about using this song'. Side effect: this SENDS AN EMAIL. It records a licensing enquiry for a work listed in the public directory and emails it to the work's owner, who can reply to the user by email (the user's address is shared with them); a confirmation email to the user is usually sent but not guaranteed. Nothing is agreed or priced: it only opens the conversation. This is the ONLY way to reach a listed work's owner: PICA never shares the owner's email address, so never draft the enquiry as an email for the user to send, and never guess an address. Sending through this tool is also what records the enquiry for the owner. ONLY call after the user has explicitly asked to send it and has given their own name, email and a description of the project. Never invent these, and never send on their behalf without asking. Get work_id from directory_lookup_work, directory_list_works or directory_chain. A 403 means the owner is not taking enquiries; a 404 means the work is not publicly listed; an unknown outcome means it may already have been sent, so never resend without asking. MORE WORKS FROM THE SAME OWNER: before sending, you may call directory_similar_from_owner and offer the user the owner's similar works. Put a work in also_work_ids ONLY if the user explicitly said yes to adding that work; never add works on your own judgement. All works go to the one owner in one enquiry (at most 10 in all); a work from another owner is refused. NOT FOR: looking up who owns a work (use directory_lookup_work). → first: directory_similar_from_owner (optional, to offer more of the owner's works) → then: directory_lookup_work (the work page and credits, to share with the user)

Input Schema

Name	Required	Description
`term`	No	For how long (optional; omit if the user didn't say).
`work_id`	Yes	The work's UUID from the directory.
`territory`	No	Where it would be used (optional; omit if the user didn't say).
`budget_notes`	No	Anything the user said about budget that isn't a single amount, e.g. a range.
`company_name`	No	The user's company or production (optional).
`contact_name`	Yes	The user's own name, as they gave it.
`project_type`	Yes	The kind of project.
`also_work_ids`	No	More works from the SAME owner to include, from directory_similar_from_owner, and only the ones the user explicitly agreed to add. Omit otherwise.
`budget_amount`	No	Proposed fee, only if the user named one (optional).
`contact_email`	Yes	The user's own email address. The owner will reply to it.
`budget_currency`	No	Three-letter currency code (default GBP).
`project_description`	Yes	How the music would be used, in the user's words.

Schema Changelog

Changes observed during successful MCP inspections.

First observedNov 4, 2026

TDQS

A4.8/5.0

Behavior5/5

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

Beyond the annotations it discloses that an email is actually sent, that the user's address is shared with the owner, that a confirmation email is 'usually sent but not guaranteed', and that nothing is agreed or priced. It also documents failure semantics (403 = owner not taking enquiries, 404 = not publicly listed, unknown outcome = may already have been sent) and the 10-work cap with cross-owner refusal.

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?

It is front-loaded with user-facing trigger phrases and ordered from side effects to prerequisites to error handling. It is dense and mostly earns its length, though the trailing arrow-based call-order summary partially repeats guidance already stated earlier.

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?

For a non-idempotent, externally-visible email-sending tool with 12 parameters and no output schema, the description covers side effects, consent requirements, identifier sourcing, multi-work constraints, and error interpretation. An agent has everything needed to call it safely.

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%, so the baseline is 3, but the description adds real meaning: where work_id comes from (lookup_work, list_works, chain), the rule that also_work_ids may only contain works the user explicitly agreed to, and the at-most-10 total across all works. It does not explain term/territory/budget fields, but the schema already covers those.

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 states a specific verb and resource: it records a licensing enquiry for a directory work and emails it to the owner. It also distinguishes itself from siblings by declaring it is 'the ONLY way to reach a listed work's owner' and explicitly excluding directory_lookup_work's purpose.

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 gives concrete trigger phrases, explicit preconditions (user must have asked and supplied name, email, project description), exclusions ('NOT FOR: looking up who owns a work'), and a suggested call order involving directory_similar_from_owner and directory_lookup_work. Alternatives and when-not-to-use are both covered.

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

All withPICA Directory 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.

Resources

Need Help?