Skip to main content
Glama
Sign In

GigXchange

by app.gigxchange
OverviewDiscussionsAdmin

Ask acts about a booking (no fee needed)

send_hire_request
DestructiveIdempotent

Send the connected member's enquiry to up to 6 GigXchange artists at once - the same "Ask these acts" request as the website. Each act gets the enquiry in their GigXchange Messages with a notification and an email, and replies there with their price and availability. No fee is offered and no booking is created. Only send what the member has asked for and confirmed in this conversation. Max 3 requests a day, counting any the member sent from the website. Requires the member's "Allow my assistant to act" switch. Not connected? Each act's profile url has a Get in touch button that sends the same request from the website.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "acts": "<acts>",
      "place": "<place>"
    },
    "name": "send_hire_request"
  }
}

Input Schema

NameRequiredDescriptionDefault
actsYesThe artists to ask, by profile SLUG from a search result (e.g. "the-nile-session"); profile ids are also accepted. 1-6.
placeYesWhere the event is - a town or venue (max 120 chars).
budgetNoOptional budget in words, e.g. "around 500" (max 40 chars).
messageNoOptional note to the acts (max 1000 chars): set times, the vibe, anything they should know.
occasionNoOptional occasion, e.g. "Wedding" (max 40 chars).
event_dateNoOptional event date, YYYY-MM-DD, today or later. Leave out for "any date".

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A4.4/5.0
Behavior4/5

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

Beyond the annotations, the description discloses real consequences: each act receives a message plus a notification plus an email, replies land in GigXchange Messages, and no booking or fee results. It also surfaces auth and quota constraints (the member's "Allow my assistant to act" switch, 3/day shared with website sends) that the annotations cannot express. The one gap is that it does not reconcile the irreversible outward send with the idempotentHint=true annotation, leaving duplicate-send behavior slightly ambiguous.

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 the core action and the most important constraint (no fee, no booking) in the opening sentence, and each subsequent sentence adds a distinct operational fact. The final "Not connected?" sentence is dense but earns its place as a routing hint, though the passage runs long and could be tightened for an agent-facing prompt.

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 mutating, quota-limited, permission-gated send with no output schema, the description covers everything an agent needs before invoking: authorization requirement, per-day cap, confirmation policy, recipient limit, and where the replies will appear. No return-value documentation is needed since the response channel (GigXchange Messages) is stated.

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%, so every parameter including slug format, place, budget, message, occasion, and date format is already documented in the schema. The description only restates the headline constraints (up to 6 acts) and adds no new meaning about individual fields. Baseline 3 is appropriate when the schema carries the semantics.

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 names a specific verb and resource: it sends the connected member's enquiry to up to six artists at once, and it explicitly equates that action with the website's "Ask these acts" flow. It also states precisely what is not created — no fee is offered and no booking is made — so an agent can distinguish this from make_offer, counter_booking, or respond_to_booking without opening any 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?

It gives an explicit precondition (only send what the member has asked for and confirmed in this conversation), an explicit hard limit (max 3 requests a day, counting website sends), and an explicit alternative path when the connection is missing (the Get in touch button on each artist's profile). The when-to-use, when-not-to-use, and fallback are all present rather than inferred.

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

All GigXchange toolsInspect
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