Skip to main content
Glama

Mirabello Immigration Intelligence

Build Source-of-Wealth Pack

build_sow_pack
Read-onlyIdempotent

Source-of-Wealth / Source-of-Funds evidence pack: given a wealth-origin type (e.g. business_sale, inheritance, ipo_liquidity_event, real_estate_sale, employment_income, crypto_asset_gains) and an optional destination context (a CBI/RBI programme, generic private-bank onboarding, trustee acceptance, or EU AML account-opening), returns the documentary evidence typically required — core + corroborating documents, the context overlay (programme SoF requirements + extra due-diligence), and common red flags. Grounded in FATF/Wolfsberg standards + programme due-diligence rules. INFORMATION ONLY — lists the evidence usually required, never asserts a case is compliant. Call with no args to list available origins and contexts.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "build_sow_pack"
  }
}

Input Schema

NameRequiredDescriptionDefault
originNoCountry the applicant is relocating FROM, as a country name.
contextNoFree-text background about the applicant's situation, used to tailor the answer.

Output Schema

NameRequiredDescriptionDefault
errorNo
termsNo
sourceNo
book_urlNo
providerNo
disclaimerNo
data_updatedNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed8 schema fields changed
    • changedOutput schema / description
      Previous value: -"Mirabello response envelope. Tool-specific fields vary; the provenance/disclaimer envelope is always present."New value: +"Mirabello envelope; tool fields vary; error only on failure."
    • removedOutput schema / properties / book_url / description
      Removed value: -"Link to request a consultation with a Mirabello specialist, for a personal case."
    • removedOutput schema / properties / data_updated / description
      Removed value: -"Date the underlying dataset was last updated."
    • removedOutput schema / properties / disclaimer / description
      Removed value: -"Information, not legal/tax/financial/immigration advice; figures indicative."
    • removedOutput schema / properties / error / description
      Removed value: -"Present only when the request could not be fulfilled."
    • removedOutput schema / properties / provider / description
      Removed value: -"Always \"Mirabello Consultancy\"."
    • removedOutput schema / properties / source / description
      Removed value: -"Attribution for the data, when it is not Mirabello Consultancy itself."
    • removedOutput schema / properties / terms / description
      Removed value: -"Acceptable-use and information-not-advice terms."
  2. Changed3 schema fields changed
    • removedOutput schema / properties / book_a_consultation
      Removed value: -{
      -  "description": "URL to book a Mirabello consultation.",
      -  "type": "string"
      -}
    • addedOutput schema / properties / book_url
      Added value: +{
      +  "description": "Link to request a consultation with a Mirabello specialist, for a personal case.",
      +  "type": "string"
      +}
    • changedOutput schema / properties / source / description
      Previous value: -"Attribution for the data."New value: +"Attribution for the data, when it is not Mirabello Consultancy itself."
  3. Changed3 schema fields changed
    • addedInput schema / properties / context / description
      Added value: +"Free-text background about the applicant's situation, used to tailor the answer."
    • addedInput schema / properties / origin / description
      Added value: +"Country the applicant is relocating FROM, as a country name."
    • addedInput schema / properties / origin / examples
      Added value: +[
      +  "South Africa"
      +]
  4. Changed1 schema field changed
    • changedOutput schema / (root)
      Previous value: -nullNew value: +{
      +  "additionalProperties": true,
      +  "description": "Mirabello response envelope. Tool-specific fields vary; the provenance/disclaimer envelope is always present.",
      +  "properties": {
      +    "book_a_consultation": {
      +      "description": "URL to book a Mirabello consultation.",
      +      "type": "string"
      +    },
      +    "data_updated": {
      +      "description": "Date the underlying dataset was last updated.",
      +      "type": "string"
      +    },
      +    "disclaimer": {
      +      "description": "Information, not legal/tax/financial/immigration advice; figures indicative.",
      +      "type": "string"
      +    },
      +    "error": {
      +      "description": "Present only when the request could not be fulfilled.",
      +      "type": "string"
      +    },
      +    "provider": {
      +      "description": "Always \"Mirabello Consultancy\".",
      +      "type": "string"
      +    },
      +    "source": {
      +      "description": "Attribution for the data.",
      +      "type": "string"
      +    },
      +    "terms": {
      +      "description": "Acceptable-use and information-not-advice terms.",
      +      "type": "string"
      +    }
      +  },
      +  "type": "object"
      +}
  5. Added

TDQS

A3.6/5.0
Behavior4/5

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

Annotations already declare readOnly/idempotent/non-destructive, and the description adds genuinely new behavioral context: output structure (core + corroborating documents, context overlay, red flags), provenance (FATF/Wolfsberg + programme due-diligence rules), and a scope caveat that it is INFORMATION ONLY and never asserts compliance. The no-arg discovery call is also a useful behavioral trait not visible in annotations.

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 deliverable and packed with substantive detail; the constraints (information only, no-arg listing) come at the end where they belong. It is a single very dense sentence-plus-tail, so slightly heavy to parse, but no sentence is filler.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

An output schema exists, so the return shape need not be spelled out, and the safety profile is covered by annotations. However, the description leaves a critical gap: after reading it, an agent still cannot reliably determine what value belongs in 'origin' — the country-versus-wealth-type conflict is unresolved in the description.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, but the description actively conflicts with it: it says 'origin' is a wealth-origin type (business_sale, crypto_asset_gains) and 'context' is a destination programme, while the schema defines 'origin' as the country the applicant is relocating FROM (example: "South Africa") and 'context' as free-text applicant background. An agent following the description would pass the wrong value type for both parameters.

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 deliverable — returns a Source-of-Wealth/Source-of-Funds documentary evidence pack — and enumerates both the origin types (business_sale, inheritance, ipo_liquidity_event…) and destination contexts (CBI/RBI, private-bank onboarding, trustee acceptance, EU AML). That is far more specific than a generic checklist. It does not name the adjacent siblings (get_document_checklist, compliance_checklist, residence_evidence_checklist), so an agent must infer the boundary itself.

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

Usage Guidelines4/5

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

Gives concrete usage contexts (CBI/RBI application, private-bank onboarding, trustee acceptance, EU account opening) and an explicit zero-argument discovery invocation: "Call with no args to list available origins and contexts." It stops short of stating when NOT to use it or which sibling to prefer for plain document checklists.

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.