SIC Codes UK
Server Details
UK SIC code lookup, GICS/ICB mapping, and Companies House search. 731 codes, 5.6M companies.
- Status
- Healthy
- 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 indicate read-only and non-destructive behavior. The description adds that the tool returns child entries at the next level and provides statistics for SIC 2026, giving useful behavioral context beyond the 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 concise sentences: first states purpose, second explains optional parameter behavior, third gives concrete stats. No fluff; information is front-loaded and easy to parse.
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?
No output schema, but the tool is simple and the description adequately explains what it returns. For a read-only browser with few parameters, it provides sufficient context to use correctly.
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 explicitly listing the system enum values and explaining that omitting parent_code yields top-level entries, enhancing the schema's meaning.
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 browses hierarchy trees of specific classification systems and returns child entries. It distinguishes from siblings like lookup_sic_code (which is for individual code lookup) by focusing on hierarchical navigation.
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 codes in a system) and how to get top-level entries by omitting parent_code. It provides clear context but does not explicitly state when not to use it or list alternatives.
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?
Beyond annotations (readOnlyHint, idempotentHint, destructiveHint=false), the description adds that the tool returns equivalent codes with confidence levels and relationship types, including details like 'unchanged, renamed, split, merged, retired, new' for SIC conversions. 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 sentences, front-loaded with the core purpose, each sentence adding distinct value: main action, return value summary, specific SIC mapping behavior. No redundant or vague language.
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?
The description adequately covers the tool's functionality given the simple parameter set (3 required strings with enums) and no output schema. It mentions return fields (codes, confidence, relationships) but could be more explicit about the response structure.
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 does not add significant meaning beyond the schema's parameter descriptions, though it provides context on the conversion outcomes (relationship types) which is tangentially related.
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 converts classification codes between four specified systems (UK SIC 2007, UK SIC 2026, GICS, ICB), using specific verbs and resources. It distinguishes itself from sibling tools, which focus on lookup or browsing rather than conversion.
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 cross-system conversion and highlights relationship types for SIC 2007/2026 mapping, but it does not explicitly state when to use this tool over alternatives like lookup_sic_code 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.
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 indicate readOnlyHint true and destructiveHint false. Description adds value by detailing the returned data (company counts, locations, etc.), which is beyond what annotations provide. 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 concise sentences: first defines action and inputs, second lists outputs, third suggests use case. No redundant or 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?
For a read-only tool with 2 simple parameters and no output schema, the description adequately covers inputs, outputs, and purpose. Could mention error handling or code validation, but not necessary for typical use.
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 parameters. The description adds meaningful examples (e.g., '62020' for SIC, '45' for GICS), providing context beyond the schema. Baseline 3 increased for added value.
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?
Clearly states it retrieves an industry intelligence profile for classification codes (SIC, GICS, ICB). Lists specific return fields: company counts, top locations, distribution, cross-classification mappings. Distinguishes from sibling tools like browse_classification_hierarchy and lookup_sic_code.
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?
Mentions it is useful for market sizing and sector analysis, implying context. However, it does not explicitly state when to use this tool over alternatives (e.g., browse_classification_hierarchy for hierarchy, lookup_sic_code for single code lookup). No when-not or exclusion guidance.
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, idempotentHint, destructiveHint. The description adds valuable behavioral details: returns hierarchy, breadcrumb, child codes, cross-classification mappings, and for SIC 2026 predecessor codes. This goes beyond annotations, though no rate limits or auth are mentioned, which is acceptable for a read-only lookup.
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 well-structured sentences. The first sentence states the purpose and systems, the second lists return values. No redundant words, perfectly 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?
Given the complexity of handling multiple classification systems, the description covers return fields comprehensively. However, it does not mention error cases (e.g., invalid code) or the exact format of results. With no output schema, this is a minor gap.
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% with good examples and enum explanations. The tool description adds minimal extra parameter meaning (e.g., 'new replacement system' for SIC 2026), but the schema already does the heavy lifting. 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 clearly states the tool looks up a classification code across multiple systems (UK SIC 2007, UK SIC 2026, GICS, ICB) and specifies what it returns. It implicitly distinguishes from sibling tools like search_sic_codes (search) and browse_classification_hierarchy (browse) by focusing on exact code 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 when you have a specific code to look up, but it does not explicitly state when to use this tool over alternatives, nor does it provide exclusions or prerequisites. The context is clear enough for an agent to infer usage.
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 non-destructive, read-only, idempotent behavior. The description adds valuable context about coverage (5.6 million companies) and specific output fields (SIC codes with full names and mappings), enhancing transparency beyond the 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?
Two sentences, front-loaded with the core action and inputs, no superfluous words. Every sentence serves a purpose.
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 lookup tool with no output schema, the description thoroughly lists returned fields (name, status, type, incorporation date, address, SIC codes with mappings) and mentions coverage, providing complete context for the 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 coverage is 100%, with both parameters well-described. The description adds confirmation that query is for name and company_number is registration number, but does not significantly expand on the schema definitions.
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 looks up a UK company by name or registration number and returns specific details including SIC codes with mappings, distinguishing it from sibling tools like search_companies which likely return less detail.
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 use for looking up company details but does not explicitly differentiate from siblings such as search_companies or search_uk_companies_by_industry, leaving the agent to infer when this tool is appropriate.
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?
Annotations already indicate readOnlyHint and idempotentHint. The description adds context about returned enriched results (SIC codes, GICS/ICB mappings, address details) and cursor pagination, which are behavioral traits 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?
Two efficient sentences: first states purpose, second enumerates filters and return 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?
Given 12 parameters all described in schema and no output schema, the description provides a good overview and includes pagination details. Minor omission: error handling for cursor is in schema but not description, yet overall 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?
Schema description coverage is 100%, and each parameter is already well-documented in the input schema. The description summarizes filter types but does not add new semantic detail 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 'Search UK companies with flexible filters' and lists specific filter types, distinguishing it from sibling tools like lookup_uk_company (single company) and search_uk_companies_by_industry (industry-specific). The verb+resource is specific.
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 flexible filtering but does not explicitly state when to use this tool over siblings or when not to use it. No alternatives or exclusions are provided.
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?
Description adds value beyond annotations by detailing output structure (ranked recommendations, relevance scores, hierarchy breadcrumbs, GICS/ICB mappings) and purpose. Annotations already indicate read-only, idempotent, non-destructive; description complements with behavioral specifics.
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-loaded with purpose and action, no redundant information. Every word is informative and 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?
Description fully addresses the tool's function and output despite no output schema. It covers what the tool returns (ranked recommendations, scores, breadcrumbs, mappings) and its use case. Sibling tools provide context for alternatives.
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% and both parameters have descriptions. Tool description does not add additional meaning beyond schema; baseline of 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?
Description clearly states the action ('Search for UK SIC 2007 codes by business activity description') and resource (SIC codes) with specific details on output (ranked recommendations, relevance scores, hierarchy breadcrumbs, cross-classifications). Differentiates 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?
Indicates usage context ('useful for finding the right SIC code for Companies House registration') and implies when to use (from a business description). Does not explicitly state when not to use or name alternatives, but context from sibling tools provides sufficient differentiation.
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 provide readOnlyHint, idempotentHint, etc.; description adds pagination behavior (cursor usage, error handling) and filtering options, enhancing transparency 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?
Two sentences, front-loaded with purpose, no filler. Efficient and well-structured.
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 core functionality, filtering, pagination, and return data; lacks output schema but description is sufficient for 10 parameters with full schema coverage.
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 description adds only marginal value (e.g., examples for code parameter). 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?
Description clearly states the tool finds UK companies by classification code (SIC/GICS/ICB), specifies returned data, and distinguishes from sibling tools like lookup_sic_code or search_companies.
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 vs alternatives; though sibling tools are listed, the description does not indicate when not to use this tool.
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!