This MCP server provides tools for Gibraltar company compliance, including tax calculations, deadline tracking, and official form generation.
POA Calculator: Calculate Payments on Account (corporate tax instalments) based on last year's tax or profit.
Deadlines: Compute all compliance deadlines (annual return, accounts filing, tax return, POA, PAYE) based on incorporation and accounting reference dates.
Annual Return: Generate a pre-filled FAR01 form as a ZIP with PDF and signing guide.
Registered Office Change: Generate forms (FREG01 + board resolution) to update registered office address, with optional director service address change.
Company Formation: Generate a full incorporation pack (FINC01, FINC02, FINC30, FINC40, FINC23) as a ZIP with formation guide.
eGov Account: Generate eGov account application forms (deposit, web filing, unique identifier) as a PDF with signing guide.
Residency Planner: Plan Gibraltar residency routes with ranked options, itemised fees, deposits, and department contacts.
Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@company-gibraltar-mcp Generate annual return for company 12345"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
Gibraltar company tools for AI agents. Calculate corporate tax payments, check compliance deadlines, and generate pre-filled PDF form packs for Gibraltar Companies House.
7 tools, no API key, no rate limiting.
Tool | Description | Returns |
| Calculate Payments on Account (corporate tax instalments) | JSON |
| Calculate all compliance deadlines for a given year | JSON |
| Generate pre-filled FAR01 annual return form | ZIP |
| Generate office change forms (FREG01 + board resolution) | ZIP |
| Generate full incorporation pack (5 FINC forms) | ZIP |
| Generate eGov account application forms | |
| Plan Gibraltar residency routes: pass known facts, get ranked routes with plans, itemised fees vs refundable deposits, department contacts, and the questions still worth asking | JSON |
Related MCP server: Bizfile MCP
npm install -g company-gibraltar-mcpOr run directly with npx (no install needed):
npx company-gibraltar-mcpAdd to ~/Library/Application Support/Claude/claude_desktop_config.json:
{
"mcpServers": {
"company-gibraltar": {
"command": "npx",
"args": ["-y", "company-gibraltar-mcp"],
"env": {
"COMPANY_GI_API_URL": "https://company.gi"
}
}
}
}claude mcp add company-gibraltar -- npx -y company-gibraltar-mcpSame configuration format in your MCP settings file:
{
"mcpServers": {
"company-gibraltar": {
"command": "npx",
"args": ["-y", "company-gibraltar-mcp"],
"env": {
"COMPANY_GI_API_URL": "https://company.gi"
}
}
}
}This MCP server is a thin wrapper around the company.gi REST API. Each tool validates input with Zod and forwards the request to the corresponding API endpoint. The actual business logic (tax calculations, PDF generation, deadline calculations) runs on the server.
JSON tools (POA calculator, deadlines) return structured data
Binary tools (annual return, office change, formation, eGov) return base64-encoded PDFs/ZIPs
Ask your AI assistant:
"Calculate my payments on account for 2026 if last year's tax was 5000"
"What are my compliance deadlines? My company was incorporated on 2023-06-15"
"Generate an annual return form for company number 12345"
"Create a company formation pack for a new company called Acme Limited"
MIT
Generate a pre-filled FAR01 annual return form for Gibraltar Companies House. Returns a ZIP containing the filled PDF and a signing guide.
| Name | Required | Description | Default |
|---|---|---|---|
| companyNumber | Yes | Gibraltar company registration number | |
| companyName | Yes | Full registered company name | |
| registeredOffice | Yes | Full registered office address | |
| returnDateDay | Yes | Annual return date day (e.g. "15") | |
| returnDateMonth | Yes | Annual return date month (e.g. "March 2026") | |
| nominalShareCapital | No | ||
| totalShares | No | ||
| shareClass | No | ||
| nominalValuePerShare | No | ||
| sharesTakenUp | No | ||
| sharesIssuedForCash | No | ||
| sharesIssuedNotCash | No | ||
| sharesPartlyPaid | No | ||
| sharesAtDiscount | No | ||
| amountCalledPerShare | No | ||
| totalCallsReceived | No | ||
| callsUnpaid | No | ||
| totalIndebtedness | No | ||
| shareholder1Name | No | ||
| shareholder1Address | No | ||
| shareholder1Occupation | No | ||
| shareholder1Shares | No | ||
| shareholder2Name | No | ||
| shareholder2Address | No | ||
| shareholder2Occupation | No | ||
| shareholder2Shares | No | ||
| shareholder3Name | No | ||
| shareholder3Address | No | ||
| shareholder3Occupation | No | ||
| shareholder3Shares | No | ||
| shareholder4Name | No | ||
| shareholder4Address | No | ||
| shareholder4Occupation | No | ||
| shareholder4Shares | No | ||
| director1Name | No | ||
| director1FormerNames | No | ||
| director1Nationality | No | ||
| director1NationalityOfOrigin | No | ||
| director1Address | No | ||
| director1Occupation | No | ||
| director2Name | No | ||
| director2FormerNames | No | ||
| director2Nationality | No | ||
| director2NationalityOfOrigin | No | ||
| director2Address | No | ||
| director2Occupation | No | ||
| director3Name | No | ||
| director3FormerNames | No | ||
| director3Nationality | No | ||
| director3NationalityOfOrigin | No | ||
| director3Address | No | ||
| director3Occupation | No | ||
| director4Name | No | ||
| director4FormerNames | No | ||
| director4Nationality | No | ||
| director4NationalityOfOrigin | No | ||
| director4Address | No | ||
| director4Occupation | No | ||
| hasSecretary | No | ||
| secretaryName | No | ||
| secretaryFormerNames | No | ||
| secretaryNationality | No | ||
| secretaryNationalityOfOrigin | No | ||
| secretaryAddress | No | ||
| secretaryOccupation | No | ||
| sicCode | No | ||
| companySize | No | ||
| numberOfEmployees | No | ||
| financialYearEndDay | No | ||
| financialYearEndMonth | No | ||
| filedByName | No | ||
| filedByAddress | No | ||
| filedByEmail | No | ||
| signatoryName | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description bears full burden for behavioral disclosure. It only states the output (ZIP containing PDF and signing guide) but does not mention authentication needs, side effects, rate limits, or whether changes are reversible. This is insufficient for a tool with 74 parameters.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise (two sentences) and front-loaded with the main purpose and output. It avoids unnecessary words. However, for a tool with many parameters, more structure might be beneficial, but conciseness itself is well-executed.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (74 parameters, low schema coverage, no output schema, no annotations), the description is vastly incomplete. It does not explain parameter usage, dependencies, or provide context for correct invocation. The agent lacks essential information to use the tool effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is only 7%, yet the description adds no parameter-specific meaning. With 74 parameters, most lacking descriptions, the agent cannot infer what data to provide. The description does not compensate for this gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool generates a pre-filled FAR01 annual return form for Gibraltar Companies House, with a specific verb and resource. It also mentions the output format (ZIP with PDF and signing guide). This distinguishes it from sibling tools which handle other company functions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool vs alternatives, no prerequisites, and no exclusions. It only implies use for annual return filing. Without usage context, an agent might misuse it or overlook required dependencies.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Generate all forms needed to incorporate a new Gibraltar company. Returns a ZIP with FINC01 application, FINC02 secretary consent, FINC30 memorandum, FINC40 model articles, FINC23 compliance statement, and a formation guide.
| Name | Required | Description | Default |
|---|---|---|---|
| companyName | Yes | Proposed company name (without "Limited" suffix) | |
| backupName1 | No | ||
| backupName2 | No | ||
| directors | Yes | At least one director is required | |
| secretaryType | No | ||
| secretaryName | No | ||
| secretaryAddress | No | ||
| secretaryCompanyNumber | No | ||
| totalShares | Yes | Total number of shares to issue | |
| shareValue | Yes | Nominal value per share in GBP | |
| shareholders | Yes | At least one shareholder is required | |
| registeredOffice | No | ||
| contactEmail | No | ||
| sicCode | No | ||
| complianceSigner | No | ||
| complianceSignerRole | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so description must fully disclose behavioral traits. It only mentions returning a ZIP with forms, but does not address permissions, side effects, data persistence, rate limits, or error conditions. The generation nature is implied but not explicit.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence conveys core purpose and output contents efficiently. However, listing six forms inline could be formatted as a bullet list for clarity, though it remains functional.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 16 parameters, nested objects, and no output schema, the description lacks completeness. It does not explain required vs optional inputs, validation rules, processing expectations, or error scenarios, making it insufficient for a complex tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is low (31%), yet the description adds no additional meaning for any parameter. It fails to explain key parameters like directors, shareholders, or registeredOffice structure beyond what the schema already provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the tool generates all forms needed to incorporate a Gibraltar company, listing specific forms in the ZIP output. It unambiguously differentiates from sibling tools like annual_return or deadlines.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Description implies usage for incorporation but provides no explicit guidance on when to use versus alternatives, no exclusions, and no context about prerequisites or when not to use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Calculate all Gibraltar company compliance deadlines for a given year. Returns annual return, accounts filing, tax return (CT1), payments on account, and PAYE deadlines based on incorporation date and accounting reference date.
| Name | Required | Description | Default |
|---|---|---|---|
| incorporationDate | Yes | Company incorporation date in YYYY-MM-DD format | |
| accountingRefMonth | No | Accounting reference date month (1-12). Defaults to 12. | |
| accountingRefDay | No | Accounting reference date day. Defaults to 31. | |
| year | No | Target year for deadlines. Defaults to current year. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It does not disclose whether the tool is read-only, requires authentication, or has side effects. As a calculation tool, it is likely safe, but the description does not confirm this.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that efficiently conveys the tool's purpose and output. While concise, it could be structured with bullet points for clarity, but it is still effective.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description lists the main deadline types returned (annual return, accounts filing, tax return, etc.), which provides sufficient context. Parameters are well-documented in the schema. However, it lacks details on return format or error handling.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, baseline 3. The description adds value by explaining how parameters (incorporationDate, accountingRefMonth, accountingRefDay) are used together to calculate deadlines, and mentions defaults for month and day.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: calculate all Gibraltar company compliance deadlines for a given year, listing specific deadline types. It distinguishes from siblings like 'annual_return' which likely covers only one deadline type.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description indicates usage based on incorporation date and accounting reference date for a target year, implying it's the comprehensive tool for Gibraltar deadlines. However, it does not explicitly exclude cases or compare to alternatives like 'annual_return' or 'poa_calculator'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Generate Gibraltar eGov account application forms. Provide at least one of: deposit (deposit account), web (web filing account), uid (unique identifier). Returns a PDF with selected forms and a signing guide.
| Name | Required | Description | Default |
|---|---|---|---|
| deposit | No | Deposit account application data | |
| web | No | Web filing account application data | |
| uid | No | Unique identifier application data |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It states the output is 'a PDF with selected forms and a signing guide', which is helpful. However, it does not disclose any side effects, authentication requirements, or rate limits. The description is adequate but not exhaustive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the purpose, and concise. Every sentence adds useful information: the first states what it generates, the second details the input requirement and output. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given there is no output schema, the description adequately explains the return value (PDF with forms and signing guide). It tells the agent to provide at least one of the three parameter types. However, it does not mention that the nested objects have required fields, which might be important for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description names the three parameters (deposit, web, uid) and briefly explains their role ('deposit account', etc.). The input schema has 100% description coverage for each sub-object (e.g., 'Deposit account application data'), so the description's additional value is minimal. It does not elaborate on the fields within each parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool generates Gibraltar eGov account application forms for three specific account types (deposit, web, uid). The verb 'Generate' and resource 'Gibraltar eGov account application forms' are specific. It distinguishes from siblings because siblings deal with other filings like annual returns or company formation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says 'Provide at least one of: deposit, web, uid', which guides the agent on which parameters to populate. However, it does not provide explicit when-to-use or when-not-to-use guidance relative to sibling tools, though the purpose is distinct enough.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Calculate Gibraltar Payments on Account. Splits the annual corporate tax liability into two equal payments due 28 February and 30 September. Provide either lastYearTax or lastYearProfit with optional taxRate.
| Name | Required | Description | Default |
|---|---|---|---|
| lastYearTax | No | Last year total tax liability in GBP. Provide this OR lastYearProfit. | |
| lastYearProfit | No | Last year taxable profit in GBP. Provide this OR lastYearTax. | |
| taxRate | No | Corporate tax rate percentage. Defaults to 15. | |
| paymentYear | No | Year for POA dates. Defaults to current year. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must convey behavioral traits. It states the calculation splits liability into two equal payments on specific dates. It does not mention that this is a non-destructive calculation, but the lack of side effects is implied. The absence of output schema information is a minor gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the main purpose, followed by parameter guidance. Every sentence is informative, with no redundancy or unnecessary detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description should hint at what the tool returns (e.g., calculated installment amounts). It does not explain the output or confirm it's a calculation with no side effects. However, for a simple calculator tool, it is mostly adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description adds value by explaining the mutual exclusivity of lastYearTax and lastYearProfit and providing defaults for taxRate and paymentYear, which is beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it calculates Gibraltar Payments on Account and specifies the split into two equal payments due on specific dates. It distinguishes from sibling tools like annual_return and company_formation, which have different purposes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives explicit parameter guidance: provide either lastYearTax or lastYearProfit with optional taxRate. It does not explicitly say when to use this tool vs. alternatives, but the distinct purpose and sibling names make usage context clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Generate forms to change a Gibraltar company registered office address. Returns a ZIP with FREG01 form, board resolution, and guide. Optionally includes FDMS02 for director service address update.
| Name | Required | Description | Default |
|---|---|---|---|
| companyNumber | Yes | Gibraltar company registration number | |
| companyName | Yes | Full registered company name | |
| currentBuilding | No | Current office building/number | |
| currentStreet | No | Current office street | |
| building | Yes | New office building/number | |
| street | Yes | New office street | |
| dateOfChange | No | Date of change in YYYY-MM-DD format | |
| signatoryName | Yes | Name of person signing the forms | |
| signatoryPosition | Yes | Position of signatory (e.g. "Director") | |
| directorName | No | Director name if also updating service address | |
| directorTitle | No | Director title (Mr, Mrs, etc.) | |
| directorDOB | No | Director date of birth in YYYY-MM-DD format |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must cover behavioral traits. It discloses that the tool generates forms and returns a ZIP, and mentions optional inclusion of FDMS02. However, it does not disclose prerequisites (e.g., company must be Gibraltar-registered), whether the forms are generated asynchronously, or how the ZIP is delivered.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences long, efficient, and front-loaded. The first sentence states the primary action and output, and the second adds an optional feature. No extraneous information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the schema covers all parameters and there is no output schema, the description adequately explains the tool's purpose and output contents. It could be more complete by describing the return format (e.g., download link) or any side effects, but as a form generation tool, the description is sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
All 12 parameters have descriptions in the schema (100% coverage). The description adds value by linking optional parameters (directorName, directorTitle, directorDOB) to the FDMS02 form and clarifying that 'building' and 'street' refer to new address. This helps the agent understand parameter groupings.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool generates forms to change a Gibraltar company registered office address, specifies the output (ZIP with FREG01 form, board resolution, guide), and mentions an optional form (FDMS02) for director service address update. This is specific and distinct from sibling tools like annual_return or company_formation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description conveys the primary use case (changing registered office address) and hints at an optional related action (director service address update). While it does not explicitly state when not to use or provide alternatives, the context is clear enough for most scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v1.0.0annual_returncompany_formationdeadlinesegov_accountpoa_calculatorregistered_office_changeScored across 6 tools
Each tool targets a distinct compliance task (e.g., formation, annual return, office change, deadlines, eGov account, tax payments). No two tools have overlapping purposes, making selection unambiguous for an agent.
All tool names use a consistent descriptive snake_case pattern (e.g., company_formation, poa_calculator, registered_office_change). No mixing of conventions or cryptic abbreviations.
Six tools cover the core lifecycle of Gibraltar company compliance without being excessive. Each tool serves a distinct purpose, and the count is well-scoped for the domain.
The tool set covers formation, annual returns, office changes, eGov accounts, POA, and deadlines. Minor gaps like dissolution or name changes are absent, but core workflows are supported.
Global B2B intelligence for AI agents: 35M+ companies, 1.6M sanctions, KYB pack. 78 tools.
Form companies, manage bank accounts, cards, invoices and more — directly from your AI coding tools.
EU/UK VAT compliance for AI agents: number validation, rate lookups, reverse-charge checks.
Validate EU, UK, AU VAT numbers for AI agents. EU ViDA e-invoicing compliance.
