F
license-
qualityD
maintenanceEnables searching for AI agents by keywords or categories, allowing users to discover tools like coding agents, GUI agents, or industry-specific assistants across marketplaces.
48
marketplace
Server Details
Search and discover credentialed operational systems on the GallanDigital marketplace.
- Status
- Healthy
- Last Tested
- Transport
- Streamable HTTP
- URL
Glama MCP Gateway
Connect through Glama MCP Gateway for full control over tool access and complete visibility into every call.
MCP client
Glama
MCP server
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.
100% free. Your data is private.
Tool Definition Quality
A4.5/5.0
Tool DescriptionsA
Average 4.7/5 across 5 of 5 tools scored.
Server CoherenceA
Disambiguation5/5
Each tool has a clearly distinct purpose: search for discovery, list_categories for browsing, fetch for listing details, get_contributor_profile for contributor info, and get_deployment_guidance for deployment guidance. There is no overlap in functionality.
Naming Consistency3/5
Tool naming is inconsistent: 'fetch' and 'search' are bare verbs, while others follow a verb_noun pattern (get_contributor_profile, get_deployment_guidance, list_categories). A uniform pattern like 'get_listing'/'search_listings' would improve predictability.
Tool Count5/5
With 5 tools covering search, categories, listing details, contributor profiles, and deployment guidance, the set is well-scoped for browsing a marketplace. Each tool serves a necessary role without redundancy.
Completeness4/5
The tool surface covers key browsing operations: discovery (search, categories), detail (fetch), contributor info, and deployment guidance. Minor gaps exist, such as the lack of a tool for listing reviews or filtering search by category directly, but the core workflow is supported.
Available Tools
5 toolsfetchAInspect
Get full detail on one published listing by its listing slug (not a contributor slug). Read-only, no authentication required (public endpoint, IP rate-limited). Returns title, description, short_description, product_story, included_components, use_cases, industry_focus, complexity_level, listing_type, product_formats, thumbnail_url, an array of pricing tiers (name, price_cents, setup_fee_cents, description, billing_interval, features), a contributor object (slug, display_name, badge_tier, bio, credential_summary, credential_badges), and a category object (name, slug). Use after search or list_categories to drill into a specific result.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| slug | Yes | The listing's slug, as returned by search (the listing-level slug, not a contributor slug). |
Tool Definition Quality
A4.6/5.0
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses behavior: 'Read-only, no authentication required (public endpoint, IP rate-limited)'. Describes return structure in detail. No annotations present, so description fully covers transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loaded with purpose and usage, then return fields. Slightly long due to detailed return description, but every sentence adds value. No redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and no annotations, the description is highly complete: explains purpose, when to use, parameter, and return structure. No gaps for the tool's complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with description of slug. Description adds value by clarifying 'listing-level slug, not a contributor slug', which prevents confusion. Baseline 3 plus extra clarification.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description specifies the verb 'Get', resource 'full detail on one published listing', and identifier 'listing slug'. It clearly distinguishes from siblings like search and list_categories by stating the scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use: 'Use after search or list_categories to drill into a specific result.' Also notes read-only and no authentication. Lacks explicit when-not but covers key usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_contributor_profileAInspect
Get a contributor's public profile and their published listings, by contributor slug (not a listing slug). Read-only, no authentication required (public endpoint, IP rate-limited). Returns display_name, bio, credential_summary, positioning_statement, badge_tier, avg_rating, review_count, pull_quote, social/website URLs, credential_badges, published_listing_count, and a listings array (slug, title, price_cents) for that contributor. Use to learn more about who built a listing returned by search or fetch -- not for looking up a listing directly.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| slug | Yes | The contributor's slug (distinct from a listing slug) -- typically found in the contributor field of a search or fetch result. |
Tool Definition Quality
A4.7/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses read-only, no auth, rate limiting, and lists return fields. Lacks details on error handling for invalid slugs, but given it's a public endpoint, this is a minor gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Concise 4-sentence paragraph. Front-loaded with main action, followed by return fields and usage context. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema, but description thoroughly lists return fields. Explains slug usage and how to obtain it from siblings. Covers all essential aspects for a single-parameter tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has one parameter (slug) with description. Description adds context about slug source ('found in contributor field of search or fetch result') and emphasizes it is not a listing slug. Schema coverage is 100%, so baseline is 3; description adds value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states 'Get a contributor's public profile and their published listings' with specific verb and resource. Distinguishes from siblings by specifying 'by contributor slug (not a listing slug)' and referencing use cases for search and fetch.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states it is read-only, no authentication required, and IP rate-limited. Provides clear when-to-use guidance ('to learn more about who built a listing returned by search or fetch') and what not to use it for ('not for looking up a listing directly').
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_deployment_guidanceAInspect
Get deployment guidance for a specific published listing, by listing slug. Read-only, no authentication required (public endpoint, IP rate-limited). Returns title, product_story, included_components, use_cases, complexity_level, product_formats, and demo_video_url when available -- setup and implementation guidance for evaluating or deploying the system after purchase. Call fetch first to confirm the listing exists and get its slug.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| slug | Yes | The listing's slug, as returned by search or fetch. |
Tool Definition Quality
A4.6/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses read-only, no authentication, rate limiting, and returned fields. Lacks error behavior details but covers key aspects without annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with no fluff; front-loaded purpose and efficient delivery of all necessary information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers purpose, usage, behavior, and parameters well for a simple tool; could mention output format but not critical without output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema covers slug with description; description adds context by linking to fetch for slug retrieval, enhancing meaning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states the tool retrieves deployment guidance for a published listing by slug, and distinguishes from sibling tools like fetch and search.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly advises to call fetch first to obtain the slug, and notes the endpoint is public and IP rate-limited.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_categoriesAInspect
Enumerate the full category tree for browsing GallanDigital's marketplace. Read-only, no authentication required (public endpoint, IP rate-limited), no parameters. Returns an array of categories, each with id, name, slug, description, parent_id, level, and display_order. Use first when browsing by category rather than searching by keyword, or to get valid category_slug values for search.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Tool Definition Quality
A5/5.0
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses read-only nature, no authentication needed, IP rate-limiting, and return structure (fields listed). With no annotations, the description fully covers behavioral traits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Four well-organized sentences: purpose, behavior, return, usage. Every sentence is essential and front-loaded. No waste.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Fully describes what the tool does, its behavior, and how it relates to siblings. No output schema needed given the clear return description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters exist, baseline is 4. The description adds value by detailing the return format and fields, which is beyond the empty schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Enumerate') and resource ('full category tree') and clearly distinguishes from sibling tools like 'search' by stating when to use this tool instead.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly advises to use when browsing by category rather than searching by keyword, or to obtain valid category_slug values for search. Also notes it is read-only and public.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
searchAInspect
Full-text search across GallanDigital's published, buyer-facing listings only. Read-only, no authentication required (public endpoint, IP rate-limited). Returns an array of listing summaries, each with title, slug, short_description, price_cents, currency, listing_type, complexity_level, category_slug, and a nested contributor object (slug, display_name). Use as the entry point for discovery -- pass a result's slug to fetch for full listing detail.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Maximum number of results to return. | |
| query | Yes | Search terms to match against listing title, description, and tags. | |
| industry | No | Optional: restrict results to listings tagged for a specific industry vertical (matches industry_focus). | |
| category_slug | No | Optional: restrict results to one category slug. Call list_categories first for valid values. |
Tool Definition Quality
A4.5/5.0
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully discloses read-only nature, authentication requirements (none), rate limiting, and return structure with exact field names. 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Very concise yet complete: three sentences covering purpose, safety/access, return format, and usage workflow. Front-loaded with the most critical information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers all essential aspects: search scope, constraints, return structure, and integration with siblings. Despite no output schema, the field enumeration compensates fully.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with well-described parameters. The description adds no additional parameter meaning beyond what the schema already provides, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Full-text search' and the specific resource 'published, buyer-facing listings only', and distinguishes itself from sibling tool 'fetch' by positioning itself as the entry point for discovery.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides clear context: read-only, no authentication, public endpoint with rate limits, and explicitly instructs to use 'fetch' for full detail. Lacks explicit when-not-to-use scenarios but gives strong directional guidance.
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!
Related MCP Servers
- Flicense-qualityCmaintenanceCentral discovery point for 361 x402 capabilities, enabling AI agents to search by task, category, or keyword and retrieve structured capability cards.
- AlicenseAqualityAmaintenanceSearch and discover AI agents, skills, prompts, bundles and MCP connectors from a curated catalog of 4500+ assets. Provides tools for searching, browsing categories, and accessing detailed information about each asset.5155MIT
- AlicenseAqualityCmaintenanceEnables AI agents to search, audit, and install open-source AI skills and MCP servers with security grading and quality scoring, directly from MCP clients.313MIT