Know what business software really costs before you buy it. Independent reviews of the tools UK businesses run on: phone systems, email, cloud, SEO, social media, content creation, domain names and VPNs. Both prices shown, every score explained, and a clear label on which products we use ourselves.
Side-by-side comparison table (Markdown) for a category, optionally limited to given provider slugs.
| Name | Required | Description | Default |
|---|---|---|---|
| slugs | No | Limit to these provider slugs; omit for the whole category | |
| category | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered by metadata. The description adds the behavioral detail that the output is a Markdown comparison table, which is useful but not extensive.
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 entire description is one sentence that front-loads the output type and format before the scope and filter. Every word adds information, with no redundancy or filler.
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 2-parameter tool with annotations and no output schema, the description conveys the essential call context: the output is a Markdown comparison table scoped to a category and optionally to specific slugs. It does not specify table columns or behavior for missing slugs, but these are minor for a simple read-only comparison.
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 only 50%: slugs has a schema description, but category does not. The tool description merely restates the parameter names ('for a category', 'limited to given provider slugs') and does not explain the category values or add meaning 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 identifies a clear resource and action: generating a side-by-side comparison table (in Markdown) for providers within a category, with optional slug filtering. It is specific enough to distinguish from get_provider (single provider) or list_providers (plain list), though it does not explicitly name those alternatives.
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 exists about when to choose this tool over list_providers, get_provider, or search. The intended use (for a category, optionally filtered by slugs) is only implied by the description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
One article as Markdown (section = comparisons | guides | reviews | news | opinion).
| Name | Required | Description | Default |
|---|---|---|---|
| slug | Yes | ||
| section | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds no behavioral details beyond the annotations. It does not mention potential errors, return format specifics, or any side effects, relying entirely on the minimal 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 very concise with a single sentence, which is good, but it omits essential information, making it under-specified rather than appropriately succinct.
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 simple nature of the tool, the description still lacks sufficient context to distinguish it from sibling tools and to understand the expected input/output relationships. It does not mention the article format details beyond 'Markdown' or how the section and slug uniquely identify an article.
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 repeats the enum values for `section` but does not explain the `slug` parameter or how the two parameters interact. The schema itself has no parameter descriptions, so the tool description provides only partial semantic coverage.
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 that the tool returns 'one article as Markdown' and lists the valid sections, but it lacks a clear verb or explicit statement that it retrieves an article by slug and section. The noun-phrase style leaves some ambiguity about the action.
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 guidance is provided on when to use this tool versus siblings like get_page, list_articles, or get_provider. The description does not mention alternative tools or selection criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
A policy/about page as Markdown: editorial-policy (scoring method), ai-transparency, about, advertise, terms, privacy-policy, cookie-policy, contact.
| Name | Required | Description | Default |
|---|---|---|---|
| slug | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, and non-destructive behavior, so the description does not need to restate safety. It adds useful behavioral context by specifying that the content is returned as Markdown and by giving the concrete set of available pages. This goes beyond what the annotations and schema alone convey.
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, compact sentence with no filler. The purpose is front-loaded and the list of valid slugs is integrated directly, making the whole definition easy to scan and act on.
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 read-only tool with one parameter, the description provides enough information to invoke it correctly: the valid slugs and the Markdown return format. Annotations cover safety and idempotence, and there is no output schema requiring return-value explanation. Nothing essential is missing.
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 only says slug is a string with minLength 1, providing no semantics. The description compensates by listing the valid slug values, which is the critical missing information for calling the tool correctly. It does not explicitly say 'slug must be one of these', but the mapping is strongly implied.
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 identifies the tool as retrieving a policy/about page and specifies the return format as Markdown. It enumerates the exact page slugs available, which makes the resource concrete. It does not explicitly contrast itself with siblings like get_article or get_provider, but the domain is clear enough.
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 by listing the available policy and about pages, which tells an agent when to pick this tool. However, it does not explicitly state when to use this instead of get_article, get_provider, or search, nor does it give exclusion criteria. The guidance is present only by inference from the listed slugs.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Full review of one provider as Markdown: verdict, pros/cons, month-to-month and annual pricing, spec sheet, disclosure.
| Name | Required | Description | Default |
|---|---|---|---|
| slug | Yes | Provider slug from list_providers | |
| category | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint false, so the safety profile is covered. The description adds valuable behavioral detail by specifying the Markdown output format and the review sections included. No contradiction 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 one tightly packed sentence with no filler. It front-loads the main purpose and then enumerates the review contents efficiently.
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 no output schema, the description appropriately covers the return format and major content sections. The two required parameters are simple and mostly covered by the schema. It could mention what happens for an invalid slug, but that is minor for this low-complexity 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 only 50%; slug has a schema description but category is only documented via its enum values. The description does not explain how category and slug relate or why both are required, but the schema is fairly self-explanatory and the description adds minimal parameter context.
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 a specific action and resource: a full Markdown review of one provider, listing exact contents. It also implicitly differentiates from sibling tools like list_providers and compare_providers by focusing on a single provider's full review.
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 this tool is for reviewing one provider, but it does not explicitly say when to use it instead of compare_providers or list_providers. There is no when-not-to-use guidance or mention of alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Published comparison articles and buying guides, optionally filtered by category.
| Name | Required | Description | Default |
|---|---|---|---|
| category | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint false, so the safety profile is well covered. The description adds that only published content appears and that category filtering is possible, but it does not mention pagination, ordering, or response shape. This is adequate but not rich.
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 one concise 9-word sentence that front-loads the verb and resource. Every word contributes meaning, with no redundant filler or restatement of the tool name.
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 read-only listing operation with one optional enum parameter and strong annotations, the description covers the essential scope and filtering behavior. The main gaps are the absence of a stated output format and no explicit routing guidance relative to search or get_article, but these are minor for successful 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?
With 0% schema description coverage, the description compensates by explaining that the sole parameter, category, filters the returned articles. The enum values are self-descriptive, and 'optionally' conveys that omitting the parameter returns the full list. This is sufficient for the single optional 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 uses a specific verb ('list') and identifies the resource ('published comparison articles and buying guides') with an optional category filter. This clearly distinguishes it from singular get_article and resource-specific siblings like list_providers.
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 its main use case—listing published articles with optional category filtering—but gives no explicit guidance about when to use this tool versus search or get_article. An agent must infer the appropriate choice from sibling names rather than from stated instructions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List the software categories Saaskly covers, with slugs and how many providers are ranked in each.
| Name | Required | Description | Default |
|---|---|---|---|
| includeEmpty | No | Include categories that are still in testing (no ranked providers). Default true. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint false, so the safety profile is covered. The description adds the return content (slugs and counts) but does not mention pagination, ordering, or other behavioral details, which is acceptable given the simplicity and annotation coverage.
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, front-loaded sentence that conveys all necessary information without redundancy. It is 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?
For a simple read-only tool with one parameter and no output schema, the description is complete. It specifies what is returned and the parameter is covered by the schema, so an agent has all the information needed to invoke it 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 description coverage is 100%, so the single parameter includeEmpty is fully documented in the schema. The description does not add extra semantic value beyond the schema, which aligns with the baseline of 3 for high schema coverage.
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?
States a specific verb ('List'), a clear resource ('software categories'), and the exact output content (slugs and provider counts). This makes it unambiguous and distinguishable from sibling tools like list_providers and list_articles, even without explicit comparison.
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 retrieving categories with their slugs and counts, so an agent can infer when to call it. However, it does not explicitly state when to prefer this over alternatives or mention any exclusions, leaving some inference to the agent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Ranked providers in a category with editorial score (0–5), one-line summary, entry price and partner disclosure.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| category | Yes | Category slug |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations declare readOnly, idempotent, and non-destructive behavior, and the description does not contradict that. It adds useful context about the response contents (editorial score, summary, price, disclosure), which enriches the behavioral picture without conflicting 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 a single, tightly written sentence with no redundancy or extraneous information. Every word contributes to explaining the tool's output.
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 provides a fairly complete picture of what the tool returns (ranked providers with specific fields) despite the absence of an output schema. It does not explain ranking methodology or the effect of 'limit', but the core context is present.
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 only 50% (only 'category' is described; 'limit' is not). The description does not add any meaning for 'limit' either, failing to compensate for the schema gap. Parameter semantics are therefore incomplete.
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 lists ranked providers for a category, with specific attributes (editorial score, summary, price, disclosure). The verb 'List' and resource 'ranked providers' are specific. It does not explicitly contrast with sibling tools like compare_providers or search, but the name and scope make the purpose distinct enough.
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 is given about when to use this tool versus search or compare_providers. The description implies its use for ranked lists, but it never states scenarios, exclusions, or conditions. This leaves the agent without clear usage direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search providers and articles by keyword (name, summary, title). Returns matches with links and .md mirrors.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint. The description adds value by specifying the return behavior: matches with links and .md mirrors. There is no contradiction 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?
A single, well-structured sentence communicates the action, scope, matched fields, and return format with no unnecessary wording. It 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?
This is a simple one-parameter read-only tool, and the description covers purpose, input semantics, and result type. Minor details like pagination or ordering are not specified, but they are not required 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 schema has 0% description coverage and only a raw 'query' field with length limits. The description compensates by explaining that the query is a keyword matched against name, summary, and title, and by indicating what the matches contain.
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 uses a specific verb ('Search') and identifies a clear resource ('providers and articles') plus the fields matched ('name, summary, title'). This clearly distinguishes it from sibling tools like list_providers, list_articles, get_provider, and get_article.
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?
It provides clear context: use when searching across providers and articles by keyword. It does not explicitly name alternatives or exclusions, but the distinction from list-style and get-style siblings is strongly implied.
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. Dates show when Glama detected each change.
compare_providersget_articleget_pageget_providerlist_articleslist_categorieslist_providerssearchClaiming proves that you control a remote MCP connector. It does not move, proxy, or interrupt the server.
Open the connector listing, choose Claim ownership, and sign in to Glama.
Complete one verification method:
GitHub identity — fastest for official registry listings. For a namespace such as io.github.alice/server, link the matching GitHub user, then choose Claim with GitHub. An organization namespace such as io.github.acme/server also needs that organization to have installed the Glama AI GitHub App and approved its permissions, because GitHub discloses organization membership only to apps it has installed. Use HTTP or DNS when it has not.
HTTP challenge — works when you can deploy a public file. Generate a token, publish the exact JSON Glama shows at /.well-known/glama.json on the same origin as the connector, then choose Check HTTP challenge.
DNS challenge — works when you control DNS but cannot change the server. Generate a token, create the exact TXT record Glama shows, wait for it to propagate, then choose Check DNS challenge.
After verification, Glama sends a confirmation email and gives you access to listing details, thumbnails, health checks, and analytics. Keep the HTTP file or DNS record in place: Glama periodically checks it and ownership remains verified while the token is discoverable.
The HTTP ownership file has this structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"claim": "glama_claim_..."
}Claim tokens are opaque, stable, and bound to the signed-in Glama account. They contain no email address or other personal information. If Glama can no longer discover a verified HTTP or DNS token, it starts a seven-day grace period before removing claim-based access. Restore the same token during that period to keep ownership verified. Never publish an email address, Glama session token, GitHub token, or connector credential as ownership proof.
If verification fails, confirm that you copied the current token exactly. The HTTP file must be public, return valid JSON with a successful HTTP response, and stay on the connector's origin. DNS changes may need more time to propagate. A claim cannot transfer to a different origin or hostname: if the connector target changes, Glama starts the grace period and the new target must be claimed separately after the previous claim is released.
For a connector linked to the official MCP Registry, registry updates continue to replace its name, description, and URL by default. After claiming, open Manage connector and enable Use Glama listing details as the source of truth if edits made on Glama should be preserved. Categories and thumbnails are always managed on Glama; registry linkage and technical connection settings continue to sync.
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
To improve your MCP server's ranking:
Claim ownership of the server listing
Complete the server profile with an accurate description and thumbnail
Provide a test profile so Glama can connect to and evaluate the server
Keep tool definitions clear and complete to earn a high Tool Definition Quality Score (TDQS)
Route real usage through the Glama Gateway; more recorded successful server uses also improve the ranking
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.
No comments yet. Be the first to start the discussion!
Add one secure layer between your agents and this server.
Each tool has a clearly distinct purpose: listing categories, providers, articles, getting specific items, comparing providers, and searching. No overlap or ambiguity.
All tools follow a consistent verb-noun pattern (compare_providers, get_article, list_categories, search), with clear and predictable naming.
8 tools is well within the ideal range for a focused content and comparison site, covering browsing, retrieval, comparison, and search without unnecessary bloat.
The set covers the core user journey: discover categories, list and compare providers, read articles, and search. Missing write/update operations, but those are not expected for a public information site, so the coverage is appropriate.