SIC Codes UK
Server Details
UK SIC code lookup, GICS/ICB mapping, and Companies House search. 731 codes, 5.6M companies.
- Status
- Unhealthy
- Last Tested
- Transport
- Streamable HTTP
- URL
- Repository
- jackmmaher/siccodes.co.uk
- GitHub Stars
- 0
Glama MCP Gateway
Connect through Glama MCP Gateway for full control over tool access and complete visibility into every call.
Full call logging
Every tool call is logged with complete inputs and outputs, so you can debug issues and audit what your agents are doing.
Tool access control
Enable or disable individual tools per connector, so you decide what your agents can and cannot do.
Managed credentials
Glama handles OAuth flows, token storage, and automatic rotation, so credentials never expire on your clients.
Usage analytics
See which tools your agents call, how often, and when, so you can understand usage patterns and catch anomalies.
Tool Definition Quality
Average 4.2/5 across 8 of 8 tools scored.
Each tool has a distinct purpose: browsing hierarchy, converting classifications, getting industry profiles, looking up codes or companies, and searching. No two tools overlap significantly, making selection unambiguous.
All tool names follow a consistent verb_noun snake_case pattern (e.g., browse_classification_hierarchy, search_sic_codes). The verbs are appropriate and the naming is predictable.
With 8 tools, the server is well-scoped for its purpose. It covers browsing, searching, converting, and looking up classification codes and company data without being too sparse or bloated.
The tools cover essential operations: browsing hierarchy, searching codes by description, converting between systems, looking up codes/companies, and getting industry profiles. Minor gaps like lacking direct retrieval of classification system metadata are acceptable.
Available Tools
8 toolsbrowse_classification_hierarchyARead-onlyIdempotentInspect
Browse the hierarchy tree of a classification system (UK SIC 2007, UK SIC 2026, GICS, or ICB). Returns child entries at the next level. Omit parent_code to get top-level entries. Use this to explore what codes exist in each system. SIC 2026 has 22 sections, 87 divisions, 287 groups, 668 classes, and 410 subclasses.
| Name | Required | Description | Default |
|---|---|---|---|
| system | Yes | Classification system to browse: sic (SIC 2007), sic2026 (SIC 2026 — the new system), gics, or icb | |
| parent_code | No | Parent code to get children of. Omit to get top-level entries (SIC sections, GICS sectors, ICB industries). |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false. The description adds useful behavioral context: the tool returns children at the next level, provides hierarchy depth for SIC 2026, and notes that omitting parent_code gives top-level entries. No contradictions.
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?
Three well-structured sentences: first states the main action, second explains the key parameter behavior, third provides concrete hierarchy sizes. No extraneous words, information is front-loaded.
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?
For a two-parameter tool with no output schema and safety annotations, the description covers the core functionality, parameter usage, and data structure. It could mention that results are paginated or limited, but overall it is sufficiently complete.
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 input schema has 100% coverage, but the description adds meaning: it clarifies that 'sic' refers to SIC 2007 and 'sic2026' to the new system, explains the effect of parent_code omission, and gives hierarchy sizes for SIC 2026. This goes 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 title and description clearly specify the tool's purpose: browsing the hierarchy tree of classification systems (UK SIC, GICS, ICB), returning child entries at the next level. It distinguishes from siblings by focusing on hierarchy exploration rather than single code lookup or search.
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 explains when to use the tool ('to explore what codes exist in each system') and how to use the parent_code parameter (omit for top-level). It does not explicitly mention when not to use or contrast with siblings, but the context is clear enough.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
convert_between_classificationsARead-onlyIdempotentInspect
Convert a classification code between UK SIC 2007, UK SIC 2026, GICS (MSCI), and ICB (FTSE Russell) systems. Returns equivalent codes in the target system with confidence levels and relationship types. Supports converting SIC 2007 codes to SIC 2026 equivalents (and vice versa) with relationship info (unchanged, renamed, split, merged, retired, new).
| Name | Required | Description | Default |
|---|---|---|---|
| to | Yes | Target classification system | |
| code | Yes | The classification code to convert (e.g. '62020' for SIC 2007, '6201' for SIC 2026, '45102030' for GICS sub-industry) | |
| from | Yes | Source classification system |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and idempotentHint, indicating safe operation. The description adds behavioral context by specifying that it returns confidence levels and relationship types, and elaborates on SIC 2007/2026 conversion relationships, going beyond what annotations provide.
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?
Two sentences with no fluff. First sentence front-loads the primary action and resource. Second sentence adds key details about SIC conversion and output information. Every sentence earns its place.
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 complexity of multiple systems and output details, the description covers core functionality well. Annotations provide safety info, and schema covers parameters. Some explicit mention of return structure could improve completeness, but it is sufficient for an agent.
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 100%, so baseline is 3. The description adds extra meaning by explaining the supported systems and the types of relationships (unchanged, renamed, etc.), enhancing understanding beyond the schema's parameter descriptions.
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 verb 'Convert' and the resource 'classification code' between specific systems (UK SIC 2007, UK SIC 2026, GICS, ICB). It details the return information (equivalent codes, confidence levels, relationship types), distinguishing it from sibling tools that focus on singular systems.
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 implies usage when conversion between classification systems is needed, but it does not explicitly state when not to use or provide alternatives. The context of sibling tools suggests differentiation, but the description itself lacks explicit guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_industry_profileARead-onlyIdempotentInspect
Get an industry intelligence profile for a SIC, GICS, or ICB classification code. Returns company counts (active vs dissolved), top geographic locations, company type distribution, and cross-classification mappings. Useful for market sizing and sector analysis.
| Name | Required | Description | Default |
|---|---|---|---|
| code | Yes | Classification code (e.g. '62020' for SIC, '45' for GICS sector, '1010' for ICB supersector) | |
| system | No | Classification system | sic |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark the tool as read-only and idempotent. The description adds behavioral details about the returned data (company counts, locations, distributions, mappings), going beyond what annotations provide without contradicting them.
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?
Two sentences that efficiently convey purpose, inputs, outputs, and use cases with no redundant content.
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?
For a simple two-parameter tool without output schema, the description adequately explains what is returned and for what purpose. It could mention if results are limited in scope, but overall complete enough.
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%. Description provides useful examples ('62020' for SIC) and notes the default system ('sic'), adding semantic clarity 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?
Description clearly states the tool retrieves an industry intelligence profile for classification codes (SIC, GICS, ICB). It lists specific returned data (company counts, top locations, etc.), distinguishing it from sibling tools like lookup_sic_code or browse_classification_hierarchy.
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 mentions 'Useful for market sizing and sector analysis,' which implies appropriate contexts. However, it does not explicitly state when not to use it or suggest alternative tools from the sibling list.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
lookup_sic_codeARead-onlyIdempotentInspect
Look up a classification code in the UK SIC 2007, UK SIC 2026 (the new replacement system), GICS (MSCI), or ICB (FTSE Russell) system. Returns the code name, hierarchy level, breadcrumb trail from root to code, child codes, and cross-classification mappings. For SIC 2026, also returns SIC 2007 predecessor codes with relationship type and confidence.
| Name | Required | Description | Default |
|---|---|---|---|
| code | Yes | The classification code to look up (e.g. '62020' for SIC 2007, '6201' for SIC 2026, 'J' for section, '45' for GICS sector, '1010' for ICB supersector) | |
| system | No | Which classification system the code belongs to: sic (UK SIC 2007), sic2026 (UK SIC 2026 — the new classification), gics (MSCI Global Industry Classification Standard), or icb (FTSE Russell Industry Classification Benchmark) | sic |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, indicating safe behavior. The description adds valuable behavioral context about the output: code name, hierarchy level, breadcrumb trail, child codes, cross-classification mappings, and SIC 2007 predecessor codes for SIC 2026. No contradictions with annotations.
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, concise and front-loaded. The first sentence states the action and systems; the second lists return values. No superfluous 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?
Despite no output schema, the description fully explains what the tool returns, including specific details like hierarchy level and cross-classification mappings. With only 2 simple parameters, the description provides complete context for agent 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?
Schema coverage is 100%, so both parameters have descriptions. The description adds meaning beyond schema by providing concrete examples (e.g., '62020' for SIC 2007) and clarifying enum options with system names. This helps the agent understand valid formats.
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: looking up a classification code in multiple systems (UK SIC 2007, UK SIC 2026, GICS, ICB). It distinguishes from sibling tools like search_sic_codes (search vs lookup) and browse_classification_hierarchy (browse vs lookup) by focusing on code lookups with specific return information.
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 implicitly tells when to use this tool (when you have a code to look up) by detailing what it returns. However, it lacks explicit guidance on when not to use it or direct references to alternatives like search_sic_codes or browse_classification_hierarchy.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
lookup_uk_companyARead-onlyIdempotentInspect
Look up a UK company registered at Companies House by name or registration number. Returns company details including name, status, type, incorporation date, registered address, and SIC codes with their full names and GICS/ICB mappings. Covers 5.6 million UK companies.
| Name | Required | Description | Default |
|---|---|---|---|
| query | No | Company name to search for (e.g. 'Tesco', 'Rolls Royce') | |
| company_number | No | Companies House registration number (e.g. '00445790') |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, etc. The description adds concrete details about returned data (status, type, SIC codes with mappings) and coverage (5.6 million companies), enhancing transparency beyond annotations. No contradictions.
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?
Two sentences front-load the purpose and efficiently list output details. 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?
For a simple lookup tool with good annotations and schema, the description covers the key aspects. It could clarify whether name search returns multiple results, but overall it is complete enough.
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% with descriptions for both 'query' and 'company_number'. The description in the main text mirrors these descriptions without adding extra semantics. Baseline 3 is appropriate as schema does the heavy lifting.
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 verb 'Look up' and the resource 'UK company registered at Companies House by name or registration number'. It distinguishes from sibling search tools by focusing on individual company lookup.
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 implies usage for single company lookup but does not explicitly state when to use this tool versus sibling search tools like 'search_companies' or 'search_uk_companies_by_industry'. No when-not-to-use guidance provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
search_companiesARead-onlyIdempotentInspect
Search UK companies with flexible filters. Combine name search, postcode, status, incorporation date range, SIC/GICS/ICB codes, accounts category, and company type. Returns enriched results with all SIC codes, GICS/ICB mappings, and address details. Cursor pagination for large result sets.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Max results (default 20, max 50) | |
| query | No | Company name to search for (min 2 chars) | |
| cursor | No | Pagination cursor from previous response. Invalid or expired cursors return an invalid_cursor error - restart pagination without the cursor parameter. | |
| status | No | Company status filter (default: all) | all |
| icb_code | No | ICB code filter (any level: 2-8 digit code) | |
| postcode | No | Postcode prefix (e.g. 'SW1', 'EC2A') | |
| sic_code | No | SIC code filter (any level: section letter, 2-5 digit code) | |
| gics_code | No | GICS code filter (any level: 2-8 digit code) | |
| company_type | No | Company type filter (e.g. 'Private Limited Company', 'PLC', 'LLP') | |
| accounts_category | No | Accounts category filter (e.g. 'MICRO-ENTITY', 'SMALL', 'MEDIUM', 'DORMANT') | |
| incorporated_after | No | ISO date (e.g. '2020-01-01') | |
| incorporated_before | No | ISO date (e.g. '2024-12-31') |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond annotations (readOnly, idempotent, openWorld, non-destructive), the description adds important behavioral context: enriched results with SIC/GICS/ICB mappings, address details, and cursor pagination with error handling for invalid cursors.
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?
Two sentences efficiently cover filters, results, and pagination. No extraneous text, but could slightly improve structure with bullet points.
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 12 parameters, all documented in schema, the description completes the picture by summarizing filter types, result enrichment, and pagination. Lacks output schema, but description suffices.
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 100%, so baseline is 3. The description lists filter categories but does not add significant new meaning beyond the schema's parameter descriptions.
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 searches UK companies with flexible filters, distinguishes from siblings like lookup_uk_company and search_uk_companies_by_industry by emphasizing multi-filter capability and enriched results.
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?
Describes when to use: combining multiple filters (name, postcode, status, dates, codes, etc.). However, it does not explicitly state when not to use or mention alternatives like lookup_uk_company for single company retrieval.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
search_sic_codesARead-onlyIdempotentInspect
Search for UK SIC 2007 codes by business activity description. Describe what a business does in plain English and get ranked SIC code recommendations with relevance scores, hierarchy breadcrumbs, and GICS/ICB cross-classification mappings. Useful for finding the right SIC code for Companies House registration.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Maximum number of results to return (default 5, max 20) | |
| query | Yes | Business activity description in plain English (e.g. 'online candle shop', 'software development', 'plumbing and heating', 'restaurant') |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds that results are ranked with relevance scores, hierarchy breadcrumbs, and GICS/ICB mappings, providing behavioral context beyond annotations.
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 consists of two concise sentences with no wasted words. The first sentence defines the core action, and the second adds valuable details and the use case.
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?
For a search tool with 2 parameters and no output schema, the description adequately explains the output (ranked recommendations, hierarchy, mappings) and provides example queries. It is complete for agent 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?
Schema coverage is 100% with clear descriptions for both parameters. The description reinforces the query parameter by mentioning 'plain English' but adds no new details beyond the schema. Baseline 3 is appropriate.
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 states 'Search for UK SIC 2007 codes by business activity description' with a specific verb and resource. It mentions ranked recommendations, hierarchy breadcrumbs, and cross-classification mappings, distinguishing it from siblings like 'lookup_sic_code' and 'browse_classification_hierarchy'.
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 notes it is 'Useful for finding the right SIC code for Companies House registration,' providing a clear use case. However, it does not explicitly state when not to use it or mention alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
search_uk_companies_by_industryARead-onlyIdempotentInspect
Find UK companies registered under a specific SIC, GICS, or ICB classification code. Returns enriched company data including all SIC codes, GICS/ICB mappings, address, company type, and incorporation date. Supports filtering by postcode, date range, accounts category, and company type. Cursor pagination for large result sets.
| Name | Required | Description | Default |
|---|---|---|---|
| code | Yes | Classification code to search by (e.g. '62020' for IT consultancy, '45' for GICS Energy sector) | |
| limit | No | Maximum number of companies to return (default 20, max 50) | |
| cursor | No | Pagination cursor from a previous response's next_cursor field. Invalid or expired cursors return an invalid_cursor error - restart pagination without the cursor parameter. | |
| status | No | Filter by company status (default: active only) | active |
| system | No | Classification system the code belongs to | sic |
| postcode | No | Postcode prefix filter (e.g. 'SW1', 'EC2A', 'M1') | |
| company_type | No | Filter by company type (e.g. 'Private Limited Company', 'PLC', 'LLP') | |
| accounts_category | No | Filter by accounts category (e.g. 'MICRO-ENTITY', 'SMALL', 'MEDIUM', 'DORMANT') | |
| incorporated_after | No | ISO date (e.g. '2020-01-01'). Only companies incorporated after this date. | |
| incorporated_before | No | ISO date. Only companies incorporated before this date. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate read-only, idempotent, non-destructive. Description adds valuable details on cursor pagination error handling and filtering capabilities, enhancing understanding beyond annotations.
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?
Three sentences, front-loaded with purpose, then enriched data, then filters and pagination. No redundant information; every sentence adds value.
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?
Covers purpose, filters, pagination, and return data hints. Lacks output schema or error details beyond cursors, but sufficient for a read-only search tool with many parameters.
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 3. Description lists filter types but does not add significant meaning beyond schema descriptions. Slight value in summarizing filters but no deeper insights.
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 finds UK companies by classification code (SIC, GICS, ICB) with specific verb 'Find'. It distinguishes from sibling tools like search_companies and lookups by focusing on industry codes.
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?
No explicit guidance on when to use this tool versus alternatives. Sibling tools exist but no comparison or exclusion criteria provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Claim this connector by publishing a /.well-known/glama.json file on your server's domain with the following structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"maintainers": [{ "email": "your-email@example.com" }]
}The email address must match the email associated with your Glama account. Once published, Glama will automatically detect and verify the file within a few minutes.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
Discussions
No comments yet. Be the first to start the discussion!