Skip to main content
Glama
Sign In

JobMojito

by com.jobmojito
OverviewDiscussionsAdmin

Submit feature request

submit_feature_request
Destructive

[Feedback] Send a feature request to the JobMojito product team. It is posted on the public feature request board under the signed-in user's name, where they get status updates; the company is not named. It takes a short title and a description of the need and why; everything sent is public. It posts the title and 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": {
      "title": "<title>",
      "description": "<description>"
    },
    "name": "submit_feature_request"
  }
}

Input Schema

NameRequiredDescriptionDefault
titleYesA short summary of the feature, shown as the post title.
llm_modelNoYour model id, e.g. "claude-opus-4-8"; "unknown" if unsure. For analytics.
descriptionYesWhat the user needs and why: the problem, how they work around it today, who it would help.
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
_mcp_instructionsNoServer-issued metadata for this conversation.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed7 schema fields changed
    • changedInput schema / properties / description / description
      Previous value: -"What the user needs and why: the problem, how they work around it today, who it would help. Plain text; blank lines separate paragraphs. The board is public: do not include candidate data, company names or other personal information."New value: +"What the user needs and why: the problem, how they work around it today, who it would help."
    • removedInput schema / properties / description / example
      Removed value: -"We review applications in a spreadsheet every Friday. Today we export each interview separately; one CSV per position would save an hour a week."
    • addedInput schema / properties / llm_model
      Added value: +{
+  "description": "Your model id, e.g. \"claude-opus-4-8\"; \"unknown\" if unsure. For analytics.",
+  "type": "string"
+}
    • removedInput schema / properties / title / example
      Removed value: -"Export all results of a position as one CSV"
    • removedOutput schema / description
      Removed value: -"The submitted feature request."
    • removedOutput schema / properties / id / description
      Removed value: -"Id of the stored request."
    • removedOutput schema / properties / status / description
      Removed value: -"`posted`: it is on the feature request board. `queued`: stored, it is posted shortly (the board could not be reached right now)."
  2. Changed3 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"
    • changedInput schema / properties / title / type
      Previous value: -[
-  "string",
-  "null"
-]New value: +"string"
  3. Added

TDQS

A4/5.0
Behavior5/5

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

Beyond the annotations, the description discloses the traits an agent most needs: the request is posted publicly under the signed-in user's name, the company is never named, everything sent becomes public, and there is an at-most-5-per-day rate limit. It also warns that the title and description are posted verbatim, which is the key behavioral fact for a write tool whose text is permanently exposed.

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?

Purpose is front-loaded and the remaining sentences carry actionable facts (public, attributed, verbatim, rate-limited) with no filler. There is minor redundancy in stating the public-board posting and "everything sent is public" as separate clauses, plus a trailing pointer to get_tool_reference.

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?

For a write tool with an output schema, the description covers the important ground: audience, attribution, permanence, verbatim publishing, and throttling. It leaves out what happens on rejection or rate-limit failure and whether a submitted request can later be edited or withdrawn, which would help an agent set user expectations.

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: it tells the agent the description should convey the need and the why, and that arguments are published exactly as given, warning against polishing or rephrasing user text. It does not mention length limits or explain the analytics-only llm_model and conversation_id parameters, which the schema already handles.

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 first sentence states a specific verb and resource ("Send a feature request to the JobMojito product team") plus the destination surface (the public feature request board), so the agent knows exactly what this does. It does not explicitly name its nearest sibling, report_technical_issue, so the feature-request-vs-bug-report boundary must be inferred from semantics rather than stated.

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?

Usage is only implied: the description makes clear this is the channel for product feature ideas, which implicitly excludes bug reports and support tickets, but it never says so or points at report_technical_issue. The stated constraints (public posting, 5 per day) function as usage guardrails but are framed as behavior, not as when-to-use guidance.

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