Skip to main content
Glama
Sign In

JobMojito

by com.jobmojito
OverviewDiscussionsAdmin

Report technical issue

report_technical_issue
Destructive

[Feedback] Report a technical problem to JobMojito support. It opens a support conversation from the signed-in user's account (their e-mail), with their company and the interview or result ids given; support answers there. The description covers what was done, what was expected and what happened (error text as shown). It sends the description exactly as given; at most 5 a day.

Every argument in full, with examples: get_tool_reference.

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": {
      "description": "<description>"
    },
    "name": "report_technical_issue"
  }
}

Input Schema

NameRequiredDescriptionDefault
llm_modelNoYour model id, e.g. "claude-opus-4-8"; "unknown" if unsure. For analytics.
result_idNoThe interview result the problem is about, if any.
descriptionYesWhat went wrong: what you did, what you expected, what happened instead (error messages as shown), and since when.
interview_idNoThe interview (definition) the problem is about, if any.
conversation_idNoThe conversation_id this server returned earlier in this conversation, unchanged, including after later user messages. Omit it if you have none. Recorded for the server developer's analytics.

Output Schema

NameRequiredDescriptionDefault
idYes
statusYes
referenceYes
_mcp_instructionsNoServer-issued metadata for this conversation.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed8 schema fields changed
    • changedInput schema / properties / description / description
      Previous value: -"What went wrong: what you did, what you expected, what happened instead (error messages as shown), and since when. Plain text; blank lines separate paragraphs. Do not include passwords or API keys."New value: +"What went wrong: what you did, what you expected, what happened instead (error messages as shown), and since when."
    • removedInput schema / properties / description / example
      Removed value: -"The PDF report of a finished interview stays empty since this morning. Other results open fine."
    • addedInput schema / properties / llm_model
      Added value: +{
+  "description": "Your model id, e.g. \"claude-opus-4-8\"; \"unknown\" if unsure. For analytics.",
+  "type": "string"
+}
    • removedOutput schema / description
      Removed value: -"The reported technical issue."
    • removedOutput schema / properties / id / description
      Removed value: -"Id of the stored report."
    • removedOutput schema / properties / reference / description
      Removed value: -"The support conversation number, once sent (e.g. `#592`)."
    • removedOutput schema / properties / reference / example
      Removed value: -"#592"
    • removedOutput schema / properties / status / description
      Removed value: -"`sent`: the support team has it. `queued`: stored, it is sent shortly (support could not be reached right now)."
  2. Changed2 schema fields changed
    • changedInput schema / properties / conversation_id / description
      Previous 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."New value: +"The conversation_id this server returned earlier in this conversation, unchanged, including after later user messages. Omit it if you have none. Recorded for the server developer's analytics."
    • changedInput schema / properties / description / type
      Previous value: -[
-  "string",
-  "null"
-]New value: +"string"
  3. Added

TDQS

A3.8/5.0
Behavior4/5

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

Annotations already declare readOnlyHint=false, destructiveHint=true and openWorldHint=true, so the description's added value is in the specifics: a support conversation is created from the user's e-mail plus company and interview/result ids, support replies in that thread, and the payload is sent verbatim. The 5-per-day rate limit is a genuinely useful behavioral fact not present in structured fields; only the practical consequence of 'destructive' (what, if anything, is altered) remains unstated.

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?

Front-loaded with the action and the side effect, then constraints, then a pointer to the reference tool — no filler sentences. Minor redundancy: the recap of 'what was done, what was expected and what happened' largely duplicates the schema text for the description field.

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?

With 5 params at full schema coverage, an output schema, and complete annotations, the description covers what an agent needs to decide and call correctly, including the rate limit and that the ticket is user-visible to support. It does not need to explain return values, and no significant gap remains.

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 baseline is 3, and the description adds real meaning on top: the description text is transmitted exactly as given (so no summarizing/paraphrasing), and interview_id/result_id are contextual links to the affected object. It also points to get_tool_reference for full per-argument examples rather than restating the schema.

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?

States a specific verb and resource: report a technical problem to JobMojito support, which opens a support conversation tied to the signed-in user. An agent can tell this apart from most siblings (e.g. submit_feature_request) by the 'technical problem' framing, though it never names that closest alternative explicitly.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Implies when to use it (a technical problem needing support follow-up) and gives a hard usage constraint of at most 5 per day, but offers no explicit when-not guidance and no routing to submit_feature_request or get_documentation for non-technical or self-serve issues.

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

All JobMojito 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