Read-only service discovery, public-page checks, and request-link preparation.
Use after a service is identified and the user needs its published scope, limits, commercial packages, sample, and terms. Does not determine eligibility or order.
| Name | Required | Description | Default |
|---|---|---|---|
| language | No | Response language: ar or en. | ar |
| service_id | Yes | One id returned by the list tool. |
| Name | Required | Description |
|---|---|---|
| ok | Yes | |
| status | Yes | |
| service | Yes | |
| catalog_version | Yes | |
| catalog_fingerprint_sha256 | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, providing the safety profile. The description adds the boundary that it does not determine eligibility or order, and lists content categories. It does not provide deeper behavioral detail, but the output schema covers return structure.
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 with no filler. The usage trigger is front-loaded, and the negative boundary is a single short sentence. Every clause 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?
For a simple read-only lookup with a rich schema and an output schema, the description covers when to use it, what content it returns, and the key exclusion. The prerequisite to first identify a service is implied but not stated as an explicit call to the list tool, which 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%: both service_id and language have clear descriptions, including the enum source and default. The description adds no extra parameter meaning beyond what the schema already gives, so the 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?
The description states a specific verb ('get') and resource ('one public service and its packages'), and enumerates the returned content: scope, limits, commercial packages, sample, and terms. It partially distinguishes from siblings through 'Does not determine eligibility or order', but does not name alternative tools explicitly.
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 explicitly conditions use on 'after a service is identified' and the user needing published service details. It also gives a clear when-not-to-use boundary: 'Does not determine eligibility or order.' However, it fails to name the exact alternative sibling tools, leaving some routing to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Use when a user asks what Advisors AI offers. Returns exactly five public services; do not use it to infer fit or to create an order.
| Name | Required | Description | Default |
|---|---|---|---|
| language | No | Response language: ar or en. | ar |
| Name | Required | Description |
|---|---|---|
| ok | Yes | |
| status | Yes | |
| services | Yes | |
| package_count | Yes | |
| service_count | Yes | |
| catalog_version | Yes | |
| deployed_channel | Yes | |
| attribution_status | Yes | |
| catalog_fingerprint_sha256 | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish readOnly, idempotent, and non-destructive behavior. The description adds useful behavioral detail by specifying the exact output count ('exactly five public services') and by constraining when the tool should not be used. This goes beyond what annotations 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?
Two short sentences, with the primary use case front-loaded and the negative constraint placed second. There is no redundant explanation, and every word contributes to selection or invocation decisions.
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 tool is simple: one optional language parameter, full schema documentation, an output schema, and extensive annotations. The description supplies the missing selection context and the exact service count. Nothing an agent needs to call this tool correctly is absent.
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% and the single language parameter is fully documented with an enum and default value. The description does not add parameter-level detail, but this is acceptable because the schema carries the semantic burden completely.
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 resource ('five public services'), and clarifies scope by stating it returns exactly five public services. It also distinguishes itself from fit/order-related tools via explicit do-not-use instructions, making it clearly separable from siblings.
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 gives an explicit trigger condition: 'Use when a user asks what Advisors AI offers.' It also states when not to use the tool ('do not use it to infer fit or to create an order'). However, it does not explicitly name the alternative tools, though sibling names like advisors_catalog_match_service and advisors_order_prepare_link make the alternatives inferable.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Use when the user describes a business need but has not chosen a service. Returns at most two deterministic routing suggestions; it is not a diagnosis or proof of fit.
| Name | Required | Description | Default |
|---|---|---|---|
| need | Yes | Business need only; do not include credentials or personal data. | |
| language | No | Response language: ar or en. | ar |
| Name | Required | Description |
|---|---|---|
| ok | Yes | |
| status | Yes | |
| question | No | |
| confidence | No | |
| claim_boundary | No | |
| scoring_method | Yes | |
| recommendations | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish read-only, idempotent, non-destructive behavior. The description adds meaningful behavioral context: results are deterministic, at most two suggestions, and not a diagnosis or proof of fit. This prevents the agent from overinterpreting the output.
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 filler. The trigger condition is front-loaded, and the determinism, result count, and epistemic limitations are conveyed in a compact, readable way.
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 output schema documents return values, annotations cover the safety profile, and the description covers the trigger, the output limit, and the interpretation caveat. Nothing essential is missing for an agent to select and invoke the tool 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 schema fully documents the 'need' and 'language' parameters, including the privacy warning for 'need'. The description reinforces that 'need' is a business need but adds little beyond the schema's own 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 title and description clearly identify a routing/matching action: it takes a business need and returns up to two service suggestions. The 'has not chosen a service' qualifier differentiates it from get/list siblings, and the disclaimer 'not a diagnosis or proof of fit' further clarifies its scope.
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 opens with an explicit trigger condition: use when the user describes a business need but has not chosen a service. It does not name sibling alternatives or give when-not-to-use exclusions, but the stated condition is clear enough for agent selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Use only after the user explicitly selects a package returned by the service tool. Returns the ordinary login/request link; it does not create an order, confirm eligibility, or charge anything.
| Name | Required | Description | Default |
|---|---|---|---|
| language | No | Request-page language: ar or en. | ar |
| package_id | Yes | Published package id returned by advisors_catalog_get_service. |
| Name | Required | Description |
|---|---|---|
| ok | Yes | |
| status | Yes | |
| package | Yes | |
| request_url | Yes | |
| creates_order | Yes | |
| charges_customer | Yes | |
| attribution_status | Yes | |
| eligibility_status | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, and non-destructive behavior, and the description adds domain-specific transparency by stating it does not create an order, confirm eligibility, or charge anything. This is useful context beyond the raw annotation flags.
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 concise sentences with the usage condition front-loaded and the behavioral exclusions clearly listed. No wasted words or redundant schema repetition.
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 tool is simple with only two parameters, full schema coverage, an output schema, and annotations covering safety behavior. The description fully covers the key prerequisite and side-effect expectations, leaving no critical gap for an agent to call 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 both language and package_id are already well documented. The description reinforces that package_id must come from a previously selected package, but adds little new parameter-level 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 states a specific verb and resource: it prepares and returns a normal login/request link for a selected package, and explicitly distinguishes itself from order creation, eligibility confirmation, and charging. This clearly separates it from the catalog and site-check sibling tools.
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 gives a strong precondition: use only after the user explicitly selects a package returned by the service tool. It also clarifies what the tool does not do, though it does not name alternative tools for those other operations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Use only when a user asks to inspect a public website. Measures bounded page, robots, structured-data, sitemap, and experimental llms.txt signals. It does not measure AI mentions, rank, visibility, firewall passage, or sales.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | Public HTTP(S) website; private networks, credentials, and unusual ports are rejected. | |
| language | No | Response language: ar or en. | ar |
| Name | Required | Description |
|---|---|---|
| ok | Yes | |
| scope | No | |
| errors | No | |
| status | Yes | |
| message | No | |
| signals | No | |
| next_step | No | |
| miss_count | No | |
| measurement | No | |
| not_measured | No | |
| score_percent | No | |
| checked_origin | No | |
| measured_at_utc | No | |
| unchecked_count | No | |
| coverage_percent | No | |
| external_data_policy | No | |
| separate_live_measurement | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint=false, so the safety profile is well covered. The description adds useful behavioral context by defining the exact scope of measurements and explicitly listing excluded metrics, giving the agent realistic expectations about what the tool can report. 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?
Two sentences with no wasted words. The most important usage constraint is front-loaded, followed by a compact list of measured signals and a compact list of exclusions. 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?
The description is complete enough for selecting and invoking the tool: it states the trigger condition, the measured signals, and the explicit limitations. The output schema is present, so return values need not be described in the text. Minor gap: 'bounded page' is not fully elaborated, and there is no mention of rate limits or failure modes, but annotations and schema cover the key safety and invocation aspects.
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 both parameters (url and language) are already documented with examples and constraints. The description does not add parameter-level detail, but it does clarify what the url will be checked for (robots, structured data, sitemap, llms.txt), which subtly informs how the url parameter is used. Baseline 3 is appropriate given the schema already carries the semantic weight.
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 ('inspect a public website') and explicitly names the resource and signal categories measured: bounded page, robots, structured-data, sitemap, and llms.txt. It also clearly states what the tool does not measure, which removes ambiguity and distinguishes it from any broader analytics tool.
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 opening instruction 'Use only when a user asks to inspect a public website' gives an explicit triggering condition. The negative list ('does not measure AI mentions, rank, visibility, firewall passage, or sales') helps an agent avoid using it for those needs, though it does not name alternative tools for those cases. Siblings are catalog/order tools, so no direct site-check alternative is available to reference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Claiming 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 or an account that owns the GitHub organization, then choose Claim with GitHub.
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!
Read-only discovery of Framekeep capabilities, security boundaries, and public resources.
Read-only byImprint service guidance and canonical public site routes.
Search PII-free opportunities, availability, and live events; prepare safe no-write form handoffs.
Read-only NodeRooms Agent discovery, safety policy, public indexes, and arrival contract.
Add one secure layer between your agents and this server.
Each tool has a clearly distinct role: listing services, fetching a specific service, matching a need, preparing an order link, and checking a site. The descriptions also explicitly state when NOT to use each tool, eliminating ambiguity.
All tools follow the consistent advisors_<domain>_<verb>_<object> pattern, using snake_case throughout. The naming clearly groups catalog, order, and site-check functionality with predictable actions.
Five tools is well-scoped for a focused service navigator: three catalog actions, one order-link action, and one site-check action. There is no obvious redundancy or bloat.
The core navigation workflow is covered: list services, get details, match needs, and prepare an order link. The server intentionally avoids eligibility checking and order creation, so the only minor gap is that follow-through to an actual order is external.