Skip to main content
Glama

Choose a JobMojito merchant

jobmojito_configuration
Read-onlyIdempotent

Show the interactive JobMojito merchant picker (UI).

ALWAYS call this when the user wants to choose, switch, or set a merchant, or when a tool needs a merchant_id and none is selected. It renders a searchable picker with clickable options. Do NOT list merchants as text or ask the user to type a name — render this picker instead. After calling it, STOP and wait for the user's selection; then pass merchant_id=<chosen id> on every JobMojito call (omit it for the user's own account).

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
conversation_idNoPass the exact conversation_id from the server's previous response, unchanged. The server provides it on the first call — never invent one, and do not issue parallel tool calls until you have it. Keep passing the same conversation_id for the rest of the conversation, including after later user messages or on a different task; do not reset it when the user starts a new request.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • changedInput schema / properties / conversation_id / description
      Previous value: -"Echo the conversation_id from the server's previous response. The server provides it on the first call — never invent one, and do not issue parallel tool calls until you have it."New value: +"Pass the exact conversation_id from the server's previous response, unchanged. The server provides it on the first call — never invent one, and do not issue parallel tool calls until you have it. Keep passing the same conversation_id for the rest of the conversation, including after later user messages or on a different task; do not reset it when the user starts a new request."
  2. Changed1 schema field changed
    • addedInput schema / properties / conversation_id
      Added value: +{
      +  "description": "Echo the conversation_id from the server's previous response. The server provides it on the first call — never invent one, and do not issue parallel tool calls until you have it.",
      +  "type": "string"
      +}
  3. First observed

TDQS

A4.6/5.0
Behavior5/5

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so safety is covered. The description adds substantial behavior beyond that: it renders a UI, it requires the agent to STOP and await user selection before proceeding, and it defines a persistent merchant_id propagation rule for all subsequent JobMojito calls. That is exactly the kind of interaction-model context annotations cannot express.

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 critical directive (render the picker, don't list text) is front-loaded, and every sentence is actionable rather than filler. It is slightly repetitive in restating the trigger as both an ALWAYS and a DO-NOT clause, but the redundancy is purposeful emphasis rather than padding.

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 single-parameter UI-rendering tool with no output schema, the description covers everything needed: when to invoke, what is displayed, that control returns to the user, and how to use the resulting merchant_id afterward. Nothing an agent needs to call this correctly is 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?

There is a single parameter, conversation_id, and the schema already documents it at 100% coverage including the lifecycle rules (pass unchanged, don't invent, don't reset). The description adds no additional meaning about this parameter, so the baseline of 3 applies. The merchant_id mentioned is not a parameter of this tool but downstream guidance.

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 renders an interactive JobMojito merchant picker UI — and implicitly distinguishes itself from text-listing siblings such as list_my_merchants by forbidding that approach. An agent can tell what this tool does and how it differs from list-oriented siblings 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 explicit trigger conditions ('ALWAYS call this when the user wants to choose, switch, or set a merchant, or when a tool needs a merchant_id and none is selected') and explicit exclusions ('Do NOT list merchants as text or ask the user to type a name — render this picker instead'). The post-call routing ('pass merchant_id=<chosen id> on every JobMojito call, omit it for the user's own account') closes the loop on what to do next.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.