company-gibraltar-mcp

Official

by Company-Gibraltar

Overview Schema Related Servers Score Discussions

TypeScript

Remote

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v1.0.0
Disambiguation5/5
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.
Naming Consistency5/5
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.
Tool Count5/5
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.
Completeness4/5
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.
Average 3.7/5 across 6 of 6 tools scored. Lowest: 2.7/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 1 commit in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior2/5
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.
Conciseness4/5
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.
Completeness1/5
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.
Parameters1/5
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.
Purpose5/5
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.
Usage Guidelines2/5
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.
Behavior2/5
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.
Conciseness4/5
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.
Completeness2/5
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.
Parameters2/5
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.
Purpose5/5
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.
Usage Guidelines3/5
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.
Behavior2/5
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.
Conciseness4/5
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.
Completeness4/5
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.
Parameters4/5
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.
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 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.
Usage Guidelines4/5
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.
Behavior3/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior3/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters4/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior4/5
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.
Conciseness5/5
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.
Completeness3/5
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.
Parameters4/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![company-gibraltar-mcp MCP server](https://glama.ai/mcp/servers/Company-Gibraltar/company-gibraltar-mcp/badges/card.svg)](https://glama.ai/mcp/servers/Company-Gibraltar/company-gibraltar-mcp)

Score Badge

Copy to your README.md:

[![company-gibraltar-mcp MCP server](https://glama.ai/mcp/servers/Company-Gibraltar/company-gibraltar-mcp/badges/score.svg)](https://glama.ai/mcp/servers/Company-Gibraltar/company-gibraltar-mcp)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

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/Company-Gibraltar/company-gibraltar-mcp'

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