Skip to main content
Glama

get_eor_vs_entity_calc

Compare costs of using an EOR versus establishing a legal entity. Input country, headcount, and salary to get cost projections, recommendation, and break-even analysis.

Instructions

Live calculation of EOR vs setting up your own legal entity given headcount + salary. Returns 1-yr and 3-yr cost comparison, recommendation, break-even estimate, pros/cons.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
countryYes
headcountYes
annual_salary_usdYes

Implementation Reference

  • The core handler function `calcEorVsEntity` that executes the EOR vs Entity calculation logic. It takes country, headcount, and annual_salary_usd, parses markup percentages and entity setup costs from COUNTRY_BRIEFS, computes 1-year and 3-year cost comparisons, and returns a recommendation with pros/cons.
    function calcEorVsEntity(country: string, headcount: number, salaryUsd: number) {
      const brief = COUNTRY_BRIEFS[country];
      if (!brief) return { error: `Unknown country: ${country}` };
    
      // Parse markup percentage range — take midpoint
      const markupMatch = brief.typical_eor_markup.match(/(\d+)-(\d+)/);
      const markupPct = markupMatch ? (parseInt(markupMatch[1]) + parseInt(markupMatch[2])) / 200 : 0.13;
    
      // Parse entity setup cost — take midpoint
      const setupMatch = brief.entity_setup_cost_usd.match(/\$([0-9KkMm,]+)-([0-9KkMm,]+)/);
      const parseAmount = (s: string) => {
        const num = parseFloat(s.replace(/[Kk,]/g, ""));
        return s.toLowerCase().includes("k") ? num * 1000 : num;
      };
      const entitySetupMid = setupMatch ? (parseAmount(setupMatch[1]) + parseAmount(setupMatch[2])) / 2 : 15000;
    
      // Parse breakeven
      const beMatch = brief.typical_eor_breakeven_employees.match(/(\d+)-(\d+)/);
      const breakeven = beMatch ? Math.round((parseInt(beMatch[1]) + parseInt(beMatch[2])) / 2) : 8;
    
      const annualPayroll = headcount * salaryUsd;
      const eorAnnualCost = annualPayroll * markupPct;
      const entityAnnualOngoing = 24000; // ~$2K/mo accounting + legal + tax filings
      const entityYear1 = entitySetupMid + entityAnnualOngoing;
      const entityYear2Plus = entityAnnualOngoing;
      const eor3Year = eorAnnualCost * 3;
      const entity3Year = entitySetupMid + entityAnnualOngoing * 3;
    
      const recommendation = headcount < breakeven
        ? `EOR — at ${headcount} employees you're below the typical break-even of ~${breakeven} for ${brief.market}. Entity setup costs (~$${entitySetupMid.toLocaleString()}) and ongoing complexity outweigh the markup savings.`
        : headcount === breakeven
          ? `Borderline — at exactly ${breakeven} employees you're at the typical break-even. Stay on EOR if growth is uncertain. Switch to entity if you're committed to scaling 2x+ in the country.`
          : `Entity — at ${headcount} employees you're above the typical break-even of ~${breakeven}. Long-term, an entity is more cost-effective. EOR remains useful for the transition period (~3-6 mo).`;
    
      return {
        country: brief.market,
        inputs: { headcount, annual_salary_usd: salaryUsd },
        eor: {
          annual_markup: `~${(markupPct * 100).toFixed(0)}% on payroll`,
          annual_cost_usd: Math.round(eorAnnualCost),
          cost_3yr_usd: Math.round(eor3Year),
          pros: ["Compliant from day 1", "No entity setup", "Easy exit if not scaling"],
          cons: ["Markup eats into margin", "Less control over benefits/perks", "Can't customize payroll"]
        },
        entity: {
          setup_cost_usd: Math.round(entitySetupMid),
          annual_ongoing_usd: entityAnnualOngoing,
          year1_total_usd: Math.round(entityYear1),
          cost_3yr_usd: Math.round(entity3Year),
          pros: ["Lower long-term cost at scale", "Full control of HR, benefits, branding", "Local presence/credibility"],
          cons: [`Setup time: ${brief.entity_setup_time}`, "Ongoing compliance burden", "Cannot easily exit"]
        },
        breakeven_estimate: `~${breakeven} employees`,
        recommendation,
        payroll_complexity: brief.payroll_complexity
      };
    }
  • Input schema definition for the tool. Defines required parameters: country (enum from COUNTRY_BRIEFS keys), headcount (integer >= 1), and annual_salary_usd (integer >= 10000).
    name: "get_eor_vs_entity_calc",
    description: "Live calculation of EOR vs setting up your own legal entity given headcount + salary. Returns 1-yr and 3-yr cost comparison, recommendation, break-even estimate, pros/cons.",
    inputSchema: {
      type: "object",
      properties: {
        country: { type: "string", enum: Object.keys(COUNTRY_BRIEFS) },
        headcount: { type: "integer", minimum: 1 },
        annual_salary_usd: { type: "integer", minimum: 10000 }
      },
      required: ["country", "headcount", "annual_salary_usd"]
    }
  • The request handler case in the switch statement that extracts args and calls calcEorVsEntity, then returns the result as JSON.
    case "get_eor_vs_entity_calc": {
      const country = args?.country as string;
      const headcount = args?.headcount as number;
      const salaryUsd = args?.annual_salary_usd as number;
      const result = calcEorVsEntity(country, headcount, salaryUsd);
      return { content: [{ type: "text", text: JSON.stringify({ module: "EOR vs Entity Calculator", ...result }, null, 2) }] };
    }
  • src/main.ts:688-689 (registration)
    Tool registration entry in the tools list, with name "get_eor_vs_entity_calc" and its description.
    name: "get_eor_vs_entity_calc",
    description: "Live calculation of EOR vs setting up your own legal entity given headcount + salary. Returns 1-yr and 3-yr cost comparison, recommendation, break-even estimate, pros/cons.",
Behavior2/5

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

No annotations exist, so the description bears full responsibility for behavioral disclosure. The description mentions 'live calculation' but does not explain what that entails (e.g., API calls, real-time data). It does not disclose mutability, safety, authentication needs, or side effects. This is insufficient for a tool with no annotation support.

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 description is concise at ~30 words, front-loading the core purpose (live calculation). It uses a list for outputs, which is clear. However, it could be slightly more structured by separating input and output descriptions more explicitly.

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?

Given the lack of output schema and annotations, the description partially compensates by listing return components (cost comparison, recommendation, etc.). However, it does not explain the country parameter, data sources, or calculation methodology. The three-input tool is adequately described for basic use but leaves gaps in understanding.

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 description coverage is 0%, so the description must add meaning. It mentions headcount and salary as inputs but does not explicitly list or explain the country parameter (though the tool name suggests it is used). It adds marginal value over the schema by linking parameters to the calculation, but fails to fully describe each parameter's role or constraints.

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 clearly states the tool's function: a live calculation comparing EOR and setting up a legal entity, given headcount and salary. It lists specific outputs (cost comparison, recommendation, break-even, pros/cons). This distinguishes it from sibling tools like get_country_eor_brief or get_full_eor_pack, which serve different purposes.

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

Usage Guidelines2/5

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

The description does not provide any guidance on when to use this tool versus alternatives. It mentions inputs but not prerequisites or scenarios where this tool is preferred over, for example, get_full_eor_pack. No when-not-to-use or alternative suggestions are given.

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

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/closermethod/eor-compliance-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server