Skip to main content
Glama

Moha: hire in the UAE

Prepare a hire for the person to confirm

prepare_hire

Prepares the hire of one employee in the UAE without an account. Returns the quote and a link: the person opens it, checks the details and creates their Moha account (or signs in), and the hire is added to their workspace. Nothing is charged or sent to the employee before that.

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": {
      "first_name": "<first_name>",
      "last_name": "<last_name>",
      "job_title": "<job_title>",
      "monthly_salary_aed": "<monthly_salary_aed>",
      "nationality": "<nationality>"
    },
    "name": "prepare_hire"
  }
}

Input Schema

NameRequiredDescriptionDefault
spouseNoTrue if a spouse will move with them on a family visa.
emirateNoWhere they will work. Defaults to Dubai.
childrenNoChildren moving with them on family visas.
insuranceNoHealth insurance plan. Defaults to standard.
job_titleYesTheir job title. It goes on the work permit, so use the real one.
last_nameYesThe employee’s last name.
your_nameNoThe name of the person you are helping, to prefill the account.
first_nameYesThe employee’s first name.
inside_uaeNoTrue if the person is already in the UAE. Defaults to false (coming from abroad).
start_dateNoWanted start date, YYYY-MM-DD. At least two weeks from today; earlier dates are moved to the earliest possible.
your_emailNoTheir work email, on their company’s domain, to prefill the account. Personal, forwarding and throwaway addresses are refused.
nationalityYesThe employee’s nationality, as a country name. Example: India.
company_nameNoThe hiring company’s name, to prefill the account.
employee_emailNoThe employee’s personal email, if known.
monthly_salary_aedYesTotal monthly package in AED: basic salary plus allowances. Example: 20000.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A3.9/5.0
Behavior4/5

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

Beyond annotations (readOnlyHint=false, destructiveHint=false, idempotentHint=false), the description discloses the key behavioral facts: nothing is charged, nothing is sent to the employee until they confirm, and the output is a quote plus a link. It stops short of saying what a repeated call does, which matters given idempotentHint=false.

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?

Two short sentences, front-loaded with the action and the return, followed by the confirmation flow. Every sentence carries information, and the 'nothing is charged' reassurance lands where it matters.

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 15-parameter creation tool, the description covers what the tool produces (quote and link) and the downstream confirmation sequence, with the schema handling all field detail. Remaining gaps are minor: no note on repeated invocation or failure handling for an explicitly non-idempotent tool.

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%, including defaults, date constraints and email rules, so the parameters are fully self-documenting. The description adds no field-level meaning beyond the schema and does not need to; baseline 3 applies.

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?

States a specific verb and resource ('Prepares the hire of one employee in the UAE without an account') and clarifies the hand-off model: a quote plus a link the employee uses to confirm and create their account. The 'without an account' qualifier implicitly separates it from prepare_account, so an agent can route without opening either schema.

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 implied rather than stated: it fits the case where the employee has no Moha account yet, and the confirmation flow is described. It never explicitly names when to prefer this over prepare_account or when to follow up with check_prepared_hire, so the agent must infer the routing.

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.

Resources