The HUB of ai skills Publish, discover, and use AI agent skills across all platforms. Connect the MCP server once and every skill on the registry becomes instantly available — no local installation needed.
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.
Average 3.7/5 across 6 of 6 tools scored.
Each tool has a distinct, well-defined purpose: search, get, pin, unpin, list pinned, and rate. No overlap or ambiguity between them.
All tools use the consistent 'ikhono_skill_' prefix followed by a descriptive verb in snake_case, creating a clear and predictable naming pattern.
Six tools is an appropriate number for managing AI skills from a catalog: search, retrieve, manage favorites, and provide feedback. No tools are missing or extraneous.
The tool set covers the full lifecycle of interacting with iKhono skills: discovery (search), retrieval (get), personalization (pin/unpin, list pinned), and feedback (rate). No obvious gaps.
ikhono_skill_getAInspectLoad a skill from iKhono by its slug. Returns the full skill content (instructions, process, templates) that you should follow to complete the user's task. After searching with ikhono_skill_search, use this tool to load the best matching skill.
| Name | Required | Description | Default |
|---|---|---|---|
| slug | Yes | The skill slug (e.g., "@alice/security-reviewer"). Get this from ikhono_skill_search results. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It states the tool returns full skill content, but does not mention any side effects, authorization needs, or idempotency. This is adequate but leaves room for more detail.
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, no fluff. The first sentence states the action and return, the second provides usage context. Perfectly front-loaded and efficient.
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 retrieval tool with one parameter, the description fully covers what the tool does, what it returns, and how to use it in sequence with search. No missing information for an agent 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 coverage is 100% for the single parameter 'slug', which already describes its purpose (skill slug from search results). The description reinforces this by mentioning the source, but adds limited additional 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 clearly states the tool loads a skill by slug, specifying it returns full content (instructions, process, templates). It distinguishes from sibling tools like ikhono_skill_search by stating it is used after searching.
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 explicitly says to use this tool after searching with ikhono_skill_search to load the best matching skill, providing clear context. It lacks explicit when-not to use, but the guidance is strong.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
ikhono_skill_list_pinnedAInspectList all skills the user has pinned. Returns pinned skills with their names, descriptions, and ratings.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It states the output includes names, descriptions, and ratings, but does not disclose ordering, pagination, or rate limits. For a simple read-only list with no parameters, this is mostly adequate, though additional context (e.g., 'ordered by most recently pinned') would be better.
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, no filler. The purpose and output are front-loaded. Every word is necessary.
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 no output schema and no annotations, the description covers the tool's purpose and return fields. However, it lacks details on ordering, pagination, or any limitations. For a tool with no parameters, it is nearly complete, but a note on the output format (e.g., array) would improve completeness.
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?
There are 0 parameters, and schema description coverage is 100%. The description adds no parameter information because none exists. Baseline 4 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 verb 'List' and the resource 'skills the user has pinned'. It distinguishes itself from sibling tools: 'ikhono_skill_get' retrieves a single skill, 'ikhono_skill_search' searches, and others are mutations. The scope is well-defined.
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 does not explicitly state when to use this tool vs alternatives. It implies through context that it lists all pinned skills, but no 'when-not' or alternative mentions are provided. The agent must infer from sibling names.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
ikhono_skill_pinAInspectPin a skill to the user's favorites so it's always available. Pinned skills are shown in the user's profile.
| Name | Required | Description | Default |
|---|---|---|---|
| slug | Yes | The skill slug to pin (e.g., "@alice/security-reviewer") |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description must disclose behavioral traits. It confirms a mutation ('pin') but does not mention any side effects, limits, or permissions required.
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, no fluff, front-loaded with action and effect.
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, so agent lacks info on return value. Description covers purpose but not what happens after pinning (e.g., success confirmation).
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 description repeats the parameter concept without adding significant new meaning beyond the schema's example.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Pin', the resource 'skill', and the result 'always available' and shown in profile. It distinguishes from sibling tools like unpin and list_pinned.
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 when-to-use or alternatives are mentioned. The description implies usage for favoriting skills but offers no guidance on when to use pin vs unpin or other siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
ikhono_skill_rateBInspectRate a skill after using it. Helps the community discover the best skills.
| Name | Required | Description | Default |
|---|---|---|---|
| slug | Yes | The skill slug to rate (e.g., "@alice/security-reviewer") | |
| stars | Yes | Rating from 1 to 5 stars | |
| review | No | Optional text review |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It discloses the community benefit but omits behavioral traits like idempotency (can a skill be re-rated?), authentication needs, or effects on existing ratings.
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 sentence that communicates core purpose without waste. It is front-loaded 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?
For a simple 3-parameter tool with 100% schema coverage and no output schema, the description is minimally adequate. However, it could be more helpful by noting that the rating is aggregated or that the star value is restricted to 1-5 (already in schema), or by clarifying if the review is optional.
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 no additional meaning beyond the schema fields; 'slug', 'stars', and 'review' are adequately described in the schema, and the description merely restates the concept of rating.
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 'Rate a skill after using it. Helps the community discover the best skills.' clearly identifies the action (rate) and purpose (community discovery). It distinguishes from sibling tools like 'pin' or 'search', though could be more specific about what 'rate' entails.
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 after using a skill, but provides no explicit when-to-use or when-not-to-use guidance relative to siblings. No alternatives are mentioned, leaving the agent to infer context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
ikhono_skill_searchAInspectSearch iKhono for AI skills that match a query. Use this when the user asks you to do something that could benefit from specialized expertise. Returns a list of matching skills with their names, descriptions, ratings, usage counts, and pin counts.
| Name | Required | Description | Default |
|---|---|---|---|
| mine | No | Set to true to show only your own skills (requires authentication) | |
| limit | No | Maximum number of results to return | |
| query | No | Search query to find relevant skills (e.g., "security review", "write tests", "api docs"). Leave empty when using mine or author filters to list all matching skills. | |
| author | No | Filter by author username (e.g., "@alice" or "alice") | |
| category | No | Filter by category (e.g., "security", "testing", "documentation") |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It states the tool searches and returns specific fields, but omits authentication requirements (e.g., for 'mine' parameter) and does not discuss rate limits, pagination, or error conditions.
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 no wasted words. First sentence states action and resource; second provides usage guidance and return value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description adequately lists return fields. It explains when to use but could be more explicit about filter behavior (e.g., query optional with mine/author). Overall complete for a search 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 coverage is 100% (baseline 3). The description adds no parameter-specific detail beyond mentioning the query concept; it does not elaborate on filters or the 'mine' flag.
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's action ('Search') and resource ('iKhono for AI skills'), and distinguishes it from siblings like 'get' and 'list_pinned' by specifying it returns a list of matching skills with detailed fields.
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?
Provides a clear use case ('when the user asks you to do something that could benefit from specialized expertise') but does not explicitly compare to alternative tools or state when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
ikhono_skill_unpinBInspectRemove a skill from the user's pinned favorites.
| Name | Required | Description | Default |
|---|---|---|---|
| slug | Yes | The skill slug to unpin |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It states the action but lacks details on side effects (e.g., user-specific scope), permissions, or reversibility. Minimal behavioral disclosure for a mutation tool.
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?
Single sentence with no redundancy; front-loaded and efficient.
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?
Adequate for a simple, single-parameter tool with no output schema; however, lacks integration context with sibling tools for a fuller picture.
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 covers 100% of parameter (slug) with description; description adds no extra meaning beyond the schema, meeting baseline but not exceeding.
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 verb 'remove' and resource 'skill from pinned favorites', distinguishing it from siblings like ikhono_skill_pin and ikhono_skill_list_pinned.
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 on when to use or not use this tool; no mention of prerequisites or alternatives, despite having sibling tools that could clarify complementary usage.
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.
No comments yet. Be the first to start the discussion!
